TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)

Dr_Acula

Ok, using Cluso's 'james' files for the moment:
1) I edited z.bat to this:

homespun024 zicog_demo009_rr092_james2 -b -d -i3 -w
zicog_demo009_rr092_james2.binary
pause

This speeds up the compilation process. Edit the spin in the Prop tool or notepad. Save the file. Run z.bat. Double click on the 'load eeprom'
Shut down the prop tool. Run the terminal program.

2) One nifty thing about the zicog is debugging. I have DRIVE__I.DSK added to the list

#else
  FindDriveBase(0, string("DRIVE__A.DSK"))              'set the SD card drive base(s)   CPM2.2
  FindDriveBase(1, string("DRIVE__B.DSK"))              'set the SD card drive base(s)
  FindDriveBase(2, string("DRIVE__C.DSK"))              'set the SD card drive base(s)
  FindDriveBase(3, string("DRIVE__D.DSK"))              'set the SD card drive base(s)
  FindDriveBase(4, string("DRIVE__E.DSK"))              'set the SD card drive base(s)
  FindDriveBase(5, string("DRIVE__F.DSK"))              'set the SD card drive base(s)
  FindDriveBase(6, string("DRVCPM_2.DSK"))              'set the SD card drive base(s)   CPM2.2
  FindDriveBase(7, string("DRVCPM_3.DSK"))              'set the SD card drive base(s)   CPM3
  FindDriveBase(8, string("DRIVE__I.DSK"))              'set the SD card drive base(s)   8MB   
#endif

Then add some debugging capture to the ports that don't exist yet (two new lines near the bottom to print the port and the byte)

'Handle Z80 IO port reads
  case io_port
    srport:                                      'Altair front panel switches register
      in_srport
    simhport:                                    'SIMH control port
      in_simhport          
    constat:                                     'Console status port.
      in_constat
    condata:                                     'Console data port
      in_condata
    statin:                                      'Altair disk status port
      in_statin
    secpos:                                      'Altair disk sector position port
      in_secpos
    dskread:                                     'Altair disk read port 
      in_dskread
    n8vem_uart_test:                            ' test port $6D
      in_test_n8vem                             ' is a byte ready returns 0 for no byte, 1 for a byte
    n8vem_uart_in:                              ' ask for input from port $68
      in_uart_n8vem                             ' get the byte
#ifdef hdskenable
    hdskport:
      in_hdskport                                'SIMH style hard disk port
#endif
    other:
      UART.transmitCharacters(string("Read from unimplemented I/O Port &H"))
      printhex(io_port)
      UART.transmitCharacters(string(" with byte &H"))
      printhex(io_data)
      UART.transmitCharacters(string(13,10))
      io_data := 0
  io_command := 0         

and

PRI on_output
'Handle Z80 IO port writes
  case io_port
    ledport:                                     'An 8 bit parallel output with LEDs attached
      out_ledport          
    simhport:                                    'SIMH control port
      out_simhport
    condata:                                     'Console data port
      out_condata
    constat:                                     'Console status port
      out_constat
    punstat:
      out_punstat                                'Punch control port
    selout:                                      'Altair disk controller select port
      out_selout
    dskcon:                                      'Altair disk function port
      out_dskcon
    dskwrit:                                     'Altair disk write port
      out_dskwrit
    n8vem_uart_out:                              ' &H68                                            
      out_n8vem_byte
#ifdef hdskenable
    hdskport:
      out_hdskport                               'SIMH style hard disk port
#endif
    other:
      UART.transmitCharacters(string("Write to unimplemented I/O Port &H"))
      printhex(io_port)     ' print the port number for debugging
      UART.transmitCharacters(string(" with byte &H"))
      printhex(io_data)
      UART.transmitCharacters(string(13,10))
  io_command := 0                                 'Set flag ready for next io

And now try to get into drive I. It prints out the following:


Write to unimplemented I/O Port &HFD with byte &H02
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H06
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H39
Write to unimplemented I/O Port &HFD with byte &HF7
Read from unimplemented I/O Port &HFD with byte &HF7
Write to unimplemented I/O Port &HFD with byte &H02
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H01
Write to unimplemented I/O Port &HFD with byte &H06
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H39
Write to unimplemented I/O Port &HFD with byte &HF7
Read from unimplemented I/O Port &HFD with byte &HF7
Write to unimplemented I/O Port &HFD with byte &H02
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H02
Write to unimplemented I/O Port &HFD with byte &H06
Write to unimplemented I/O Port &HFD with byte &H00
Write to unimplemented I/O Port &HFD with byte &H39
Write to unimplemented I/O Port &HFD with byte &HF7
Read from unimplemented I/O Port &HFD with byte &HF7
Write to unimplemented I/O Port &HFD with byte &H02

etc

Then tried uncommenting this line
#define hdskenable 'Uncomment for hard disk support
and added this line

PRI in_hdskport_read | r
'Handle read from hdskport during a disk read command
'This read triggers the actual disk sector transfere
'and must return an error code.
'N.B. sectors are mapped to blocks 1 to 1
  UART.transmitCharacters(string("hdisk read "))

and it then gets to hdisk read.

But further down

PRI in_hdskport_write
'Handle read from hdskport during a disk write command
'This read triggers the actual disk sector transfere
'and must return an error code.
'N.B. sectors are mapped to blocks 1 to 1
  if hdsk_check_dts                                 'Check drive, track and sector are sane
    io_data := $FF                                  'Return error if not
    return
#ifdef TriBladeProp
  '???
#else

Not sure what the '??? means, at this point I'm stuck. Any help would be most appreciated.

Post Edited (Dr_Acula) : 8/17/2009 8:15:47 AM GMT

Cluso99

Sorry James... this is over to heater as I didn't know what to do.

But, do we really require hard disks (hence code complexity) if we can up the floppies size to 8MB (or indeed 32MB if we up the sectorsize to 512B)??? There is really no difference between floppies and hard drives as they are all being emulated on the one SD card anyway. That was one objective in choosing the fixed size of 32MB. So 8x32MB=256MB which should be fine for CPM, and remember, we can always add a routine to remount (remap) a floppy to a different file anyway.

Next thing James is to get the bst compiler running - no code changes required. It has the editor and downloader inbuilt plus a teminal program to boot! However, I cannot get bst to recognise my USB port under Vista. It will archive everything too. If you have an issue with the font, download and install the latest PropTool 1.2.6 which fixes it.

I have been looking at the SD drivers this afternoon.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula

But, do we really require hard disks (hence code complexity) if we can up the floppies size to 8MB (or indeed 32MB if we up the sectorsize to 512B)??? There is really no difference between floppies and hard drives as they are all being emulated on the one SD card anyway

Ah, so floppies can go to 8mb? How do you do that? I'm getting only 984k (see at the bottom) - is that right?

A>dirx

Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
ASM     COM    8K ! EXZ80ALLCOM   12K ! SBASIC  COM   26K ! UNERA   COM    2K
BASICLIBREL   42K ! EXZ80DOCCOM   12K ! SHOWSEC COM    4K ! UNLOAD  COM    2K
BOOT    COM    2K ! FORMAT  COM    2K ! SID     COM    8K ! USERLIB REL    2K
BOOTGEN COM    2K ! HALT    COM    2K ! SPEED   COM    2K ! USQ     COM    2K
CCPZ    TXT   40K ! HDIR    COM    2K ! STAT    COM    6K ! W       COM    4K
CONIN   ASM    2K ! L80     COM   12K ! SUBMIT  COM    2K ! WS      COM    8K
COPY    COM    2K ! LOAD    COM    2K ! SUPERSUBCOM    4K ! WS      OVR   52K
CPU     COM    2K ! M80     COM   20K ! SURVEY  COM    2K ! WSMSGS  OVR   14K
DD      TXT    2K ! MBASIC  COM   24K ! SYSCOPY COM    2K ! XFORMAT COM    4K
DDT     COM    6K ! NEW     BAS    2K ! SYSCPM2 SUB    2K ! XMODEMP COM    4K
DDTZ    COM   10K ! NEW     COM    4K ! SYSCPM2ZSUB    2K ! XMODEMQ COM    4K
DIR     TXT    2K ! OVERLAYBCOM    8K ! TEST    BAK    2K ! XSUB    COM    2K
DIRX    COM    4K ! PACMAN95COM   18K ! TEST    TXT    2K ! ZASM    SUB    2K
DUMP    COM    2K ! PIP     COM    8K ! TIMER   COM    2K ! ZSID    COM   10K
ED      COM    8K ! R       COM    4K ! TS      SUB    2K ! ZTRAN4  COM    4K
EX8080  COM   12K ! RSETSIMHCOM    2K ! UNCR    COM    8K
63 File(s), occupying 472K of 984K total capacity
182 directory entries and 512K bytes remain on A:
A>

heater

Dr_A: Your hard disk investigations look good so far. I will try very hard to have a few hours free to help with this this evening (7 hours away here)
I have to remind myself how it was all supposed to work!

Cluso: I think we should stick to the idea of having the 8 SIMH compatible floppy disks and up to 4 SIMH compatible hard disks. Because then:

1) We don't need to create and maintain a customized BIOS to create new sizes of floppy disks
2) All disks can be compatible with SIMH, just drop them into ZiCog and they work.
3) The SIMH hard drives use DMA rather than fetching individual bytes. Should be faster. Floppies do not unless we change the BIOS (See 1)
4) The SIMH style hard drives can be customised (size, geometry) on the fly in Spin with no CP/M BIOS hacking. Just change the disk parameter table.
5) RAM disk should be hard drives and use the disk parameter table for definition.
6) All the code is in place already and most of it has been shown to work already.

Think that's about it[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater

Dr_A: Making the floppies bigger requires changes to the CBIOSX.
I'd rather not get into that. I'd like to be able to run all the SIMH CP/M with no or as few changes as possible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

James: I think that size comes from the floppy size on the SIMH disk. You could try a format of one of the blank drives an see what that gives (I have done this before).

Heater: OK sounds great. We should therefore set the sector size to 512Bytes. Does 4x32MB drives sound good or do you want them bigger ??

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater

Yes, for hard disks sector size should match the SD block size to make best use of the SD card and the virtual DMA for speed.

If I remember correctly 32M is the limit for CP/M 2 but we can go much bigger for CP/M 3.
What I have been fishing for is a CP/M guru is knows how to tweak the disk parameter tables to do this.
Not to mention suitable params for a RAM disk.

If we can't find a guru it's back to studying the CP/M customization manuals....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

OK, lets limit it to 32MB disks. They are done already and the same will work for CPM2 & 3

I am not sure about virtual DMA. Remember, the sram is shared with the SD card so we cannot actually implement this as it will be way too slow!!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula

I tried creating a blank 32mb file (=8mb drive) which makes DRIVE__Z.CPM in the vb6 program and then renamed it DRIVE__B.DSK
but it still comes up as less than a mb.

Attached is the little DIRX program as this gives the space used and the space left and the directory. Sort of a combination of stat and dir

Then I read heaters comment. Does that mean drives A-H are 1mb and I, J, K L are 8mb each?

I see a parameter in the spin code that limits the number of drives to 8 - is that relevant?

'The following taken from SIMH Altair simulator CBIOSX.MAC
ndisks = 8 ' total number of Altair disks

The N8VEM parameter blocks seem different - not sure if this will be relevant or not but these are the parameter blocks for the 448k ram disk
1mb rom disk, 8mb hard disk and a 1mb hard disk. But perhaps stick with the simh ones

DPBLK0:                ; DISK PARAMETER BLOCK (ROMDISK 32KB WITH 16 2K TRACKS, 22K usable)
SPT_0:    .DW  16            ; 16 SECTORS OF 128 BYTES PER 2K TRACK
BSH_0:    .DB  3            ; BLOCK SHIFT FACTOR (SIZE OF ALLOCATION BLOCK)
BLM_0:    .DB  7            ; PART OF THE ALLOCATION BLOCK SIZE MATH
EXM_0:    .DB  0            ; DEFINES SIZE OF EXTENT (DIRECTORY INFO)
DSM_0:    .DW  31            ; BLOCKSIZE [noparse][[/noparse]1024] * NUMBER OF BLOCKS + 1 = DRIVE SIZE
DRM_0:    .DW  31            ; NUMBER OF DIRECTORY ENTRIES
AL0_0:    .DB  10000000        ; BIT MAP OF SPACE ALLOCATED TO DIRECTORY
AL1_0:    .DB  00000000        ; DIRECTORY CAN HAVE UP TO 16 BLOCKS ALLOCATED
CKS_0:    .DW  0            ; SIZE OF DIRECTORY CHECK [noparse][[/noparse]0 IF NON REMOVEABLE]
OFF_0:    .DW  5            ; FIRST 5 TRACKS TRACKS RESERVED (10K FOR SYSTEM)
                ; SYSTEM IS ROM LOADER, CCP, BDOS, CBIOS, AND MONITOR
                ; 
                ; IMPORTANT NOTE: TRACKS $00 - $04 OF 2K BYTES
                ; EACH ARE MARKED WITH THE OFF_0 SET TO 5 AS 
                ; SYSTEM TRACKS. USABLE ROM DRIVE SPACE
                ; STARTING AFTER THE FIFTH TRACK (IE, TRACK $05)
                ; MOST LIKELY FIX TO THIS IS PLACING A DUMMY
                ; FIRST 10K ROM CONTAINS THE ROM LOADER, MONITOR,
                ; CCP, BDOS, BIOS, ETC (5 TRACKS * 2K EACH)

DPBLK1:                ; DISK PARAMETER BLOCK (RAMDISK 512K, 448K usable)
SPT_1:    .DW  256        ; 256 SECTORS OF 128 BYTES PER 32K TRACK
BSH_1:    .DB  4            ; BLOCK SHIFT FACTOR (SIZE OF ALLOCATION BLOCK)
BLM_1:    .DB  15            ; PART OF THE ALLOCATION BLOCK SIZE MATH
EXM_1:    .DB  1            ; DEFINES SIZE OF EXTENT (DIRECTORY INFO)
DSM_1:    .DW  225        ; BLOCKSIZE [noparse][[/noparse]2048] * NUMBER OF BLOCKS + 1 = DRIVE SIZE
DRM_1:    .DW  255        ; NUMBER OF DIRECTORY ENTRIES
AL0_1:    .DB  11110000        ; BIT MAP OF SPACE ALLOCATED TO DIRECTORY
AL1_1:    .DB  00000000        ; DIRECTORY CAN HAVE UP TO 16 BLOCKS ALLOCATED
CKS_1:    .DW  0            ; SIZE OF DIRECTORY CHECK [noparse][[/noparse]0 IF NON REMOVEABLE]
OFF_1:    .DW  1            ; 1 TRACK RESERVED [noparse][[/noparse]FIRST 32K OF RAM]

DPBLK2:                ; DISK PARAMETER BLOCK (IDE HARD DISK 8MB)
SPT_2:    .DW  256        ; 256 SECTORS OF 128 BYTES PER 32K TRACK
BSH_2:    .DB  5            ; BLOCK SHIFT FACTOR (SIZE OF ALLOCATION BLOCK)
BLM_2:    .DB  31            ; PART OF THE ALLOCATION BLOCK SIZE MATH
EXM_2:    .DB  1            ; DEFINES SIZE OF EXTENT (DIRECTORY INFO)
DSM_2:    .DW  2017        ; BLOCKSIZE [noparse][[/noparse]4096] * NUMBER OF BLOCKS + 1 = DRIVE SIZE
                ; HD PARTITION 2 IS 16128 SECTORS LONG
                ; AT 512 BYTES EACH WHICH IS 
                ; 2016 BLOCKS AT 4096 BYTES A PIECE.
DRM_2:    .DW  511        ; NUMBER OF DIRECTORY ENTRIES
AL0_2:    .DB  11110000        ; BIT MAP OF SPACE ALLOCATED TO DIRECTORY
AL1_2:    .DB  00000000        ; DIRECTORY CAN HAVE UP TO 16 BLOCKS ALLOCATED
CKS_2:    .DW  0            ; SIZE OF DIRECTORY CHECK [noparse][[/noparse]0 IF NON REMOVEABLE]
OFF_2:    .DW  1            ; 1 TRACK (32K) RESERVED FOR SYSTEM

DPBLK3:                ; DISK PARAMETER BLOCK (IDE HARD DISK 8MB)
SPT_3:    .DW  256        ; 256 SECTORS OF 128 BYTES PER 32K TRACK
BSH_3:    .DB  5            ; BLOCK SHIFT FACTOR (SIZE OF ALLOCATION BLOCK)
BLM_3:    .DB  31            ; PART OF THE ALLOCATION BLOCK SIZE MATH
EXM_3:    .DB  1            ; DEFINES SIZE OF EXTENT (DIRECTORY INFO)
DSM_3:    .DW  2017        ; BLOCKSIZE [noparse][[/noparse]4096] * NUMBER OF BLOCKS + 1 = DRIVE SIZE
                ; HD PARTITION 3 IS 16128 SECTORS LONG
                ; AT 512 BYTES EACH WHICH IS 
                ; 2016 BLOCKS AT 4096 BYTES A PIECE.
DRM_3:    .DW  511        ; NUMBER OF DIRECTORY ENTRIES
AL0_3:    .DB  11110000        ; BIT MAP OF SPACE ALLOCATED TO DIRECTORY
AL1_3:    .DB  00000000        ; DIRECTORY CAN HAVE UP TO 16 BLOCKS ALLOCATED
CKS_3:    .DW  0            ; SIZE OF DIRECTORY CHECK [noparse][[/noparse]0 IF NON REMOVEABLE]
OFF_3:    .DW  1            ; 1 TRACK (32K) RESERVED FOR SYSTEM

DPBLK4:                ; DISK PARAMETER BLOCK (IDE HARD DISK 1024K)
SPT_4:    .DW  256        ; 256 SECTORS OF 128 BYTES PER 32K TRACK
BSH_4:    .DB  4            ; BLOCK SHIFT FACTOR (SIZE OF ALLOCATION BLOCK)
BLM_4:    .DB  15            ; PART OF THE ALLOCATION BLOCK SIZE MATH
EXM_4:    .DB  0            ; DEFINES SIZE OF EXTENT (DIRECTORY INFO)
DSM_4:    .DW  497        ; BLOCKSIZE [noparse][[/noparse]2048] * NUMBER OF BLOCKS + 1 = DRIVE SIZE
                ; HD PARTITION 4 IS 4032 SECTORS LONG
                ; AT 512 BYTES EACH WHICH IS 
                ; 1008 BLOCKS AT 2048 BYTES A PIECE.
                ; NOT USING ALL OF THE AVAILABLE SECTORS SINCE THIS
                ; DRIVE IS INTENDED TO EMULATE A ROM DRIVE AND COPIED
                ; INTO A ROM IN THE FUTURE.
DRM_4:    .DW  255        ; NUMBER OF DIRECTORY ENTRIES
AL0_4:    .DB  11110000        ; BIT MAP OF SPACE ALLOCATED TO DIRECTORY
AL1_4:    .DB  00000000        ; DIRECTORY CAN HAVE UP TO 16 BLOCKS ALLOCATED
CKS_4:    .DW  0            ; SIZE OF DIRECTORY CHECK [noparse][[/noparse]0 IF NON REMOVEABLE]
OFF_4:    .DW  1            ; 1 TRACK RESERVED [noparse][[/noparse]FIRST 32K OF PARTITION]

This is my altair simh 'super cp/m computer' that I use for testing. Seems the same one as for the zicog. Drive I is correctly reporting 8mb with dirx. Just need to find the block parameters and port that over to the zicog??

d tracks[noparse][[/noparse]0-7] 254
attach dsk cpm2.dsk
attach dsk1 basic.dsk
attach dsk2 games.dsk
attach dsk3 sbasic.dsk
attach dsk4 supercalc.dsk
attach dsk5 tools.dsk
attach dsk6 wordstar.dsk
attach hdsk i.dsk
set cpu 64k
set cpu noitrap
set cpu z80
set cpu altairrom
set cpu nonbanked
reset cpu
set sio ansi
set sio nosleep
boot dsk
bye

and a printout of it running:

C:\N8VEM\AltairSIMH>altairz80 all

Altair 8800 (Z80) simulator V3.7-3 build 1016 (scp created Apr 20 2008 at 13:01:
09 with gcc 4.2.3)

64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07)

A>dirx
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
ASM     COM    8K ! EXZ80DOCCOM   12K ! SID     COM    8K ! UNLOAD  COM    2K
BOOT    COM    2K ! FORMAT  COM    2K ! SPEED   COM    2K ! USQ     COM    2K
BOOTGEN COM    2K ! HALT    COM    2K ! STAT    COM    6K ! W       COM    4K
CCPZ    TXT   40K ! HDIR    COM    2K ! SUBMIT  COM    2K ! WS      COM    8K
COPY    COM    2K ! L80     COM   12K ! SUPERSUBCOM    4K ! WS      OVR   52K
CPU     COM    2K ! LOAD    COM    2K ! SURVEY  COM    2K ! WSMSGS  OVR   14K
DDT     COM    6K ! M80     COM   20K ! SYSCOPY COM    2K ! XFORMAT COM    4K
DDTZ    COM   10K ! MBASIC  COM   24K ! SYSCPM2 SUB    2K ! XSUB    COM    2K
DIRX    COM    4K ! PACMAN95COM   18K ! SYSCPM2ZSUB    2K ! ZASM    SUB    2K
DUMP    COM    2K ! PIP     COM    8K ! TIMER   COM    2K ! ZSID    COM   10K
ED      COM    8K ! R       COM    4K ! TS      SUB    2K ! ZTRAN4  COM    4K
EX8080  COM   12K ! RSETSIMHCOM    2K ! UNCR    COM    8K
EXZ80ALLCOM   12K ! SHOWSEC COM    4K ! UNERA   COM    2K
50 File(s), occupying 370K of 984K total capacity
198 directory entries and 614K bytes remain on A:
A>i:
I>dirx
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
CP409DOCARK   68K ! K1KERM11LBR   16K ! ZORK1   COM   12K ! ZORK2   DAT   92K
CP411HEXARK  156K ! LU      COM   20K ! ZORK1   DAT   84K ! ZORK3   COM   12K
CP411SRCARK  436K ! UNARC   COM    8K ! ZORK2   COM   12K ! ZORK3   DAT   92K
12 File(s), occupying 1008K of 8136K total capacity
987 directory entries and 7128K bytes remain on I:
I>

heater

Cluso:

I think 32Mb hard drives will be fine at least for now, perhaps forever,
we don't have to hack any CP/M driver parameters to do that.

We already discussed the "Virtual DMA" for hard drives, as usual I will have to try to remind my self of what we concluded[noparse]:)[/noparse]
Thing is for floppy drives each byte in/out goes through a Z80 IN/OUT opcode emulation and hence through all the
Spin code that traps and performs that so even when the the complete sector buffer is sitting in HUB (which it is anyway) that is a lot of overhead.
I would think that there must be away to blit the entire sector buffer from HUB to CP/M space in external RAM in one hit whilst the actual Z80 emulation is
stopped waiting for completion. In fact I though you had already attempted to do that. I will have to look again.

Dr_A:

We can't just make the floppies bigger with bigger image files. The floppy geometry is fixed in the CBIOS.
The SIMHH BIOS can be built with a configurable number of floppies, can save CP/M memory by using fewer. Max is 8 so that is what is in the Spin emulation.

For drive I and up SIMH has totally different driver code in the BIOS. For floppies it is Altair floppy compatible. For hard drives it has variable size/geometry disks
where the geometry descriptor blocks are fetched by the CBIOS from the hd emulator at run time. So to change hd disk size/geometry it is a Spin cnage

When you say "Drive I is correctly reporting 8mb with dirx. Just need to find the block parameters and port that over to the zicog?? "
That is correct and it is ALREADY in the ZiCog spin code.

Don't forget I have been aiming for SIMH compatibility all along.

I try and have more time for this later today.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

James: Here is v094. Could you please check it before I post at the top of this thread.(it is untested)

You will need to uncomment the·#define CPU_Z80 line in ZiCog009_rr090 (bst would not otherwise zip the project).
I have added· #define·addLF which outputs a LF following CR in·the FDX object (new mode).

If all is ok, please uncomment the 4·lines from ZiCog009_demo_rr094 before the #endif as shown (careful of indents)

PRI WriteSRAMblock | i, r, mask, in
  r := tbp2.start
  check_error(r)
#ifdef diskboot
  'clears ram $0000-$EFFF, loads $FF00-$FFFF, loads sram disk above
  'remember we are reading 8KB blocks, so clear the seven blocks and 8KB-128B of eighth block
  if blockno < 8
    'TV.dec(blockno)
    if blockno == 7
      repeat i from 0 to count-1 -(256)                 'clear below $FF00
        buff[noparse][[/noparse]i] := 0                                    'clear the buffer
    else
      repeat i from 0 to count-1
        buff[noparse][[/noparse]i] := 0                                    'clear the buffer
      if blockno == 0
        buff[noparse][[/noparse]0] := $C3                                  'force jmp to $FF00 (faster)
        buff[noparse][[/noparse]1] := $00
        buff[noparse][[/noparse]2] := $FF
#endif

 

This should improve the boot speed - causes a direct jump to the disk boot code $FF00


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula

Close but getting a hang after this (doesn't give the A> prompt)

ZiCog v0.009 on the TriBladeProp v0.09x
8 bit, parity=None, 1 stop bit, Flow control=None

Starting disks...
A:DRIVE__A.DSK
B:DRIVE__B.DSK
C:DRIVE__C.DSK
D:DRIVE__D.DSK
E:DRIVE__E.DSK
F:DRIVE__F.DSK
G:DRVCPM_2.DSK
H:DRVCPM_3.DSK
Loading SRAM...
................................................................................
................................................Loaded
Starting TriBladeProp driver ...
 Passed, please wait...
Starting Z80 emulation... Passed, please wait...


64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07)

Unknown console status write with byte &H03

More experiments, random key presses eventually brings up the A> prompt but none of the characters are echoed.

More more experiments, going back to the serial object v002, that gets to the A prompt but the characters on the keyboard are coming back as different characters eg i came back as a u.

What changed from this version (see attached)

Post Edited (Dr_Acula) : 8/17/2009 1:08:41 PM GMT

Cluso99

James: Should just have been a tidyup. Have you #define hdskenable uncommented? Hard disk is not working on the TriBlade yet - this could be getting into an incorrectly handled error.·Did you have Drive I enabled?

There are a few extra lines·you put in for debugging.

Do you have WinDiff ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Kye

Ah, not quite cluso. The whole reseaon I used 256 byte buffers is to exploit the fact that a while using a byte head and tail pointer they have automatic wrap arround.

return ((inputHead - inputTail) & $FF)

Is actually the simpliest way to calculate amount of stuff in the FIFO buffer. Great ain't it? It's also more usefull than just know if there is stuff or isn't stuff because it allows you to know the amount in the buffer.

...

Well, unless anyone has any results on my driver working now or not I'll be moving on to other things.

Cluso99 said...
James: It was a 5 second mod to add the call names like Kye's. You are reading way too much complexity into all this
Granted that Kye's code let you look for the actual problem.

Kye: Thanks for your code - it helped solve the real bug of dropping characters.
I think there is a bug in the·rxavail call.

PUB rxavail '' 3 Stack Longs
'' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
'' │ Returns the number of characters in the receiver buffer.                                                                 │
'' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
  return ((inputHead - inputTail) & $FF)

·Should be...

PUB rxavail '' 3??? Stack Longs
'' ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
'' │ Returns the number of characters in the receiver buffer.                                                                 │
'' └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
  if inputHead >= inputTail
    return ((inputHead - inputTail) & $FF)
  else
    return ((inputHead + $FF - inputTail)) & $FF)

Is it necessary to know the number of received characters in the buffer? If not, then this may be simpler..

PUB rxavail : truefalse
'' Check if byte(s) available
'' returns true (-1) if bytes available
  truefalse := rx_tail <> rx_head

BTW can you use a constant to define the length of the buffers like I did with the recent posting of the modified FDX for James·(also pasm needs to use the constant also)

CON
  bufsiz = 256 '16              'buffer size (16, 32, 64, 128, 256, 512) must be factor of 2, max is 512
  bufmsk = bufsiz - 1           'buffer mask used for wrap-around ($00F, $01F, $03F, $07F, $0FF, $1FF)

VAR
  byte  rx_buffer[noparse][[/noparse]bufsiz]           'transmit and receive buffers
  byte  tx_buffer[noparse][[/noparse]bufsiz]

  rx_tail := (rx_tail + 1) & bufmsk  'example of use

Kye, we should probably continue this under your SerialEngine post as there may be input from others. I also have some other ideas for you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Cluso99

Kye: I am quite familiar with the wrap-around technique. I suggested using a constant so that the buffer size can be changed easily, instead of looking for all the hard-coded literals.

Now, won't ((inputHead - inputTail) & $FF) give an incorrect result when the inputHead is near the beginning of the buffer and inputTail is near the end of the buffer? That is, the inputHead has just wrapped around to the beginning. In this instance you will get a negative answer and you cannot just·& of the upper bits?? That is why I checked for this condition and added the buffer length to it to get the correct length - Ah, but I should have added $100 (bufsiz), not $FF (bufmsk) !!
Just thinking about it, you should call it rxcount or rxnumber (like you did before)·as rxavail tends to imply a true/false answer.

PUB rxcount
if inputHead >= inputTail
return ((inputHead - inputTail) & $FF)
else
return ((inputHead + $100 - inputTail)) & $FF) '<==fix

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 8/17/2009 2:12:34 PM GMT

Cluso99

Heater & Dr_Acula: For testing the hard disk, if we change the hard disk parameters to be the same as a floppy we can substitute a floppy file for initial testing. Once running we can adjust the size.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater

I have a hard disk image that I have used for testing on the demo board.

Basically I copied a bunch of files from A: to I: under SIMH and dropped the resulting file into ZiCog.

I have successfully read directories and read/written to it. I'll dig it out in a couple of hours.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

James: Apologies, my error - in translating from rxnumber to rxavail the test was reversed - fixed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Cluso99

v096 attached· - a little more tidyup and a little more (hopefully) to get hdisk closer. Writes are disabled until reads work correctly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Kye

This tread goes fast!!!

Cluso99:

If you feel more comfortable with that way then go ahead and do it!

I've very sure my technique works however, I been testing it without flaws for a while now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 8/17/2009 8:16:29 PM GMT

Cluso99

@Kye: My apologies - there is no bug in your ReceiveNumber code (called rxnum below).

Currently lacking hardware at the moment, I was not able to see my flaw. Since I had to go through examples to prove it,·I thought I would post what I did for others to see... The cyclic buffer method is used in other·code such as FullDuplexSerial.

Here is an example. Lets say for simplicity, the buffer is 256 bytes in length and begins at hub $1000.

Head points to the relative position in the buffer where the next byte will be stored. Tail points to the relative position in the buffer where the last character was obtained from. When head == tail there is no data available in the buffer. Head increments each time a byte is placed into the buffer and Tail increments when a byte is taken from the buffer. Both wrap-around at the end of the buffer to the beginning of the buffer by ANDING the result with the buffer length - 1. A 256 byte buffer is ANDED with $FF. If more bytes than the buffer length are added into the buffer before they are taken, then depending on the code, either a block of bytes are lost (equal to the buffer size and the oldest) or the new bytes are lost until space is available.

When empty the head and tail point to 0 (which is $1000 + 0). Fine.

When 10 bytes have been input, the header = 10 and tail = 0. rxnum = (head - tail) & $FF·= (10 - 0) & $FF·= 10. So correct.

When 257 bytes have been input and 254 bytes taken, header = (0 + 257) & $FF = 01, tail = (0 + 254) & $FF = 254
So rxnum = head - tail = (1 - 254)· & $FF = -253 & $FF = $FFFF_FF03 & $FF = 3. So you are correct and my apologies.

Note: 10 = $0A, 254 = $FE, 257 = $101.

@OBC: You are welcome to add·this to your Tips and Traps :-)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula

Sorry for the delay.

Good and bad news.
Ok, good news is that the past post by Cluso works and I think we are now getting back to a common file between us!
Even better news, the bst compiler doesn't give any warnings. (suggestion, maybe include bst.bat and bstc.exe in the package - only adds a tiny bit to the storage on the forum)

The bad news is that the carriage return/line feed is still a muddle. It went from overprinting with no line feeds to now putting in two line feeds!

I found the reason - not in the main program but in the fullduplexserial object.

' Optionally add LF after CR

  if rxtx_mode &%10000 and txbyte == CR 
    repeat until (tx_tail <> (tx_head + 1) & bufmsk)
    tx_buffer[noparse][[/noparse]tx_head] := LF
    tx_head := (tx_head + 1) & bufmsk

    if rxtx_mode & %1000
      rx

I think I can see the reason you have put it there, because CP/M outputs CRLF after each line and I think the terminal program you are using treats CR as if it is CRLF. Or something like that - I'm not sure why you are not getting double spacing either.

Anyway, I'm preferring to stay with standard terminal programs like Hyperterm and Teraterm and remote Telnet and also down the track, the PockeTerm (see attached). I wonder if the terminal you are using could be edited?

CP/M outputs 13 then 10 after each line. The bootup sends just 13, and 10 if you want to add it.

The idea I have is to leave out the ifdefs, delete all references to CR, even delete CR and LF as definitions in the main program. Just a philosophical thing too, but a uart object really should just be sending and receiving bytes, not modifying those bytes.

All the bootup lines have crlf as the next line eg

  UART.str(string("ZiCog v0.009 on the TriBladeProp v0.09x"))
  crlf
  UART.str(string("8 bit, parity=None, 1 stop bit, Flow control=None"))
  crlf   

And then you just change this line here and comment out the LF if you don't want it. So it becomes one line to change which is as simple as an ifdef. (you could even add that deletion as an ifdef if required)

PRI crlf
  UART.tx(13)
  UART.tx(10)

Attached zip of code with crlf added and a photo of it running on the PockeTerm

Addit: tried re including these lines but didn't make any difference to the speed:

'<== probably can speedup by enabling this
     if blockno == 0
       buff[noparse][[/noparse]0] := $C3                                  'force jmp to $FF00 (faster)
       buff := $00
       buff := $FF

Post Edited (Dr_Acula) : 8/18/2009 3:36:12 AM GMT

Dr_Acula

Ok, major housekeeping. What I was debugging the program looking for the missing characters I went through and commented out lots of lines eg tv.hex and tv.dec because these did not exist in the serial driver. Those changes have ended up being left in, so time to fix them up.

All tv.hex changed to UART.hex and uncommented
All tv.dec changed to UART.dec and uncommented
All commented out instances of CR uncommented, and replaced with crlf
Many messages now included again, especially hard drive messages. While it is being debugged etc, better to have these messages. They can always be commented out again later.

I hope this is all ok, but it was kind of my fault this highly commented out version is persisting.

Cluso99

Thanks James. I will grab it later tonight
Sorry, I didn't understand that CPM output CR+LF whereas ZiCog demo was not.

re bst - you must have warnings turned off as there sould be 3 warnings about # missing in jmps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Cluso99

Heater: Here is the latest code (per James with·changes and comments)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Dr_Acula

That works. Looking at a common file we can work on, can you pls re-release that with the baud rate at 115k, and try the LF commented out.

I'll change those two things on my working file (and hopefully remember to change them if I upload a new package).

Then you can use the terminal you are using. (my inability to go above 38k baud speed is due to the long serial cable. 38k is more than fast enough for me!)

I must say that is is amazing watching xmodem work. Also, I know I said those 4 lines

'<== probably can speedup by enabling this
     if blockno == 0
       buff[noparse][[/noparse]0] := $C3                                  'force jmp to $FF00 (faster)
       buff := $00
       buff := $FF

didn't make a difference to the boot speed. They don't, but something has dramatically increased the speed of file writes when doing an xmodem file transfer.

All looking good!

So - on to the next phase. I've pondered all sorts of ways to get the bigger disk images, but keep coming back to heater's comment that it is best to keep this as a simh simulation. Use the simh standards. I was tempted at one stage earlier today to get into the cbios settings and make the floppy drives bigger, but I think heater is right. Keep the first 8 drives as 1mb, and then the next 4 as 8mb. Down the track, maybe we can get a link to the zicog on the simh site (as the N8VEM managed to do once it was stable).

Heater, I spent 4 months procrastinating building a triblade. Cluso was very patient, and he even sent me a freebie sd socket at one stage. So I know the board can be a bit daunting, but are you stuck with one particular part missing, or is the build a bit confusing? I know this might be a bit odd to hassle you like this, but I feel like a smoker who has just quit and now has gone all evangelical about it. The triblade is great!!! If you need a ram chip or something, pls let me know so I can send you one.

Was there a thought at one stage of using faster sd access code? Is this possible (it would be great if it is!)

heater

Dr_A: Only just today I managed to find time to sit down with ZiCog and find out what you guys are up to.
Looks like you have been doing great. I have just now managed to download your latest files and get them running on my Demo Board.

Re: Hard Disks. I just noticed a comment in zicog_demo under the HD descriptors that the sector size can be increased
from 128 bytes BUT NOT for CP/M 2 only CP/M 3. I don't know if that is a limitation of CP/M 2 or just the CBIOSX we are using with it.
It occurs to me that as we are 512 byte SD card blocks to hold 128/137 byte sectors, which is waste full anyway, we would get a 4 times
speed up of disk access using 512 byte sectors on hard disks under CP/M 3 !!! Not to mention the speed gain we get by using "virtual" DMA
instead of the byte at a time transfers of the floppy disks.

So we should aim to
1) Get hard disks working
2) Get CP/3 in general use
3) Increase the sector size to 512
4) Add more tracks etc.

Re: My TriBlade, The major problem is the lack of time. But given my list of objectives above I really should try harder to get on to it.
If you have a spare RAM chip that would be great [noparse]:)[/noparse]

For the rest of today I am going to try and recreate the experiments I did with the hard disk driver emulation.
I feel sure that it pretty much works. Just need to demonstrate it to you guys.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 8/18/2009 2:44:20 PM GMT

heater

Dr_A: Just noticed in that screen shot above here that your BIOS is v1.25 from 15-JAN-2007.
I'm using (SIMH ALTAIR 8800, BIOS V1.27, 1 HD, 02-May-2009).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Cluso99

James: Those lines will not increase the speed after boot.
However, I increased the FDX buffer size to 256 (previously 16) and this could account for speed improvement. You can make it 512 if you like - just edit the CON section in FDX.
OK with the baudrate. I will not re-release just for that - I can that change easily. Heater is looking at the hard drive tonight so may have some fixes. I think we may need a N8VEM #define at some time, so could adj baudrate in there.
Heater and I emailed today and we are both going to use FDX (provided he has no problems tonight).
I am unable to try LF at the moment - no hardware :-(

re Heater's TriBlade - I think he has just been flat out with other things. I took photos and wrote instructions when I built my second TriBlade a week or so ago. However, I only built Blade #2 and the power & USB so far. Thats all I needed for running ZiCog. James, be careful about the ram chips. Heater may want to use them in something else LOL.

I cannot play with the faster fsrw SD code. I have been having a look though. Should pretty much drop in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

heater

Just to whet your appetite...

With no fuss at all I have hard drive I: working. At least for reads.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.