This is a bit simplistic maybe, but I just copied the existing hard drive parameters and made the drive smaller. Would that work?
It certainly works as a hard drive.
ZiCog v0.10 on the TriBladeProp v0.102
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
I:DRIVE__I.DSK
J:DRIVE__J.DSK
K:DRIVE__K.DSK
L:DRIVE__L.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.27, 2 HD, 02-May-2009)
A>i:
I>stat
A: R/W, Space: 242k
I: R/W, Space: 708k
I>a:
A>pip i:mbasic.com=a:mbasic.com
................................................................................
................................................................................
..................................
A>i:
I>dirx
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
MBASIC COM 24K
1 File(s), occupying 24K of 708K total capacity
1023 directory entries and 684K bytes remain on I:
I>mbasic
BASIC-80 Rev. 5.21
[noparse][[/noparse]CP/M Version]
Copyright 1977-1981 (C) by Microsoft
Created: 28-Jul-81
32824 Bytes free
Ok
10 print "hello"
run
hello
Ok
system
I>
with parameters
dpb_0 '720K Super I/O Floppy, for use as RAM disk ?
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $05 'data allocation Block SHift factor
:blm BYTE $1F 'data allocation block mask
:exm BYTE $01 'EXtent Mask
:dsm_low BYTE $B8 'maximum data block number (low_byte)
:dsm_high BYTE $00 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $03 'total number of directory entries (high byte)
:al0 BYTE $FF 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)'
' 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
and that is the same as the 8mb ones except dsm_low and dsm_high are different.
Hmm - something is wrong with the variables [noparse][[/noparse]colon]psh and [noparse][[/noparse]colon]phm in this forum. (which I can't display of course with a colon!) Displays correctly when editing but not correctly in the viewing. Just need to watch that with future cut and pastes.
cross posted: That is great news, so we only have to shrink to be 768KB (or whatever) and reformat a blank drive and copy whatever we want to be in the ramdrive
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'll sleep on this. The boot track number could be less for instance. And the number of file entries. I guess just tweak one thing at a time and retest.
Re "james: might you have to format the drive first ?"
My "formatted" drives are simply 32meg images filled with E5. To erase a drive I and start again, I just copy the new blank file over to the sd card, erase the old DRIVE__I.DSK and rename the blank file as DRIVE__I.DSK. So no need for a format program for the moment. One could write one in CP/M but at the current write rate for an sd card, the above process is a lot quicker.
Dr_Acula:
Here is modified code for placing the ramdisk as drive I: (replaces all hard drives) so boot from A: and format I: (because I do not initialise·the Ram Disk·correctly) and then pip to it and try it. The dpb_0 will have to reflect a reduced size also.
You will need to place a new #define RamHDisk in the top section of the demo.
I am retiring for the night also.
PRI in_hdskport_read | r
'Handle read from hdskport during a disk read command
'This read triggers the actual disk sector transfer 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
'++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#ifdef RamHDisk
'read the block from RamDisk (sram) <=== Note could do direct block move sram -> sram
sd_block := (hdsk_track * 32) + hdsk_sector 'offset within the RamHDisk
err := tbp2.DoCmd("R", @disk_buff, sd_block*128 + disk_offset, 128)
#else
r := tbp2.idle 'give up the bus
CheckError(r)
r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD
CheckError(r)
' this method relies on the SD file using contiguous sectors !!! Only the first 128 bytes of 512 bytes used
sd_block := (drive_base[noparse][[/noparse]hdsk_drive+8]) + (hdsk_track * 32) + hdsk_sector '8x floppies, then 4x hdisks
err := sd.readSDCard(sd_block, @disk_buff, 128) 'read a sector
' CheckError(err)
r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)
CheckError(r)
r := tbp2.active 'activate the bus
CheckError(r)
#endif
'++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
if err
UART.str(string("Error hdisk read "))
DisplayError(err)
DisplayHDiskDTS
io_data := $FF 'Return error code
else
'write the block out to sram
r := tbp2.DoCmd("W", @disk_buff, hdsk_dma, 128) 'Virtual "DMA" the sector into DMA buffer address in SRAM
check_error(r)
io_data := $00 'Return OK.
'----------------------------------------------------------------------------------------------
#else
sd_block := hdsk_base_block 'Start at first block of first HD
sd_block := sd_block + hdsk_drive * (32 * 2048) 'Skip on to the first block of the selected drive
sd_block := sd_block + (hdsk_track * 32) + hdsk_sector 'Find correct block for the selected track/sector
err := \disk.readblock(sd_block, @disk_buff ) 'Read the block !
if err
UART.str(string("Error hdisk read "))
DisplayError(err)
DisplayHDiskDTS
io_data := $FF 'Return error code
else
BYTEMOVE (@ram_z80 + hdsk_dma, @disk_buff, 128) 'Virtual "DMA" the sector into DMA buffer address in Z80 RAM
io_data := $00 'Return OK.
#endif
'----------------------------------------------------------------------------------------------
hdsk_last_command := hdskNull 'Command completed
PRI in_hdskport_write | r
'Handle read from hdskport during a disk write command
'This read triggers the actual disk sector transfer 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
'read the block from sram
r := tbp2.DoCmd("R", @disk_buff, hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer address from SRAM
check_error(r)
'++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#ifdef RamHDisk
'write the block to RamDisk (sram) <=== Note could do direct block move sram -> sram
sd_block := (hdsk_track * 32) + hdsk_sector
err := tbp2.DoCmd("W", @disk_buff, sd_block*128 + disk_offset, 128)
#else
r := tbp2.idle 'give up the bus
CheckError(r)
r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD
CheckError(r)
' this method relies on the SD file using contiguous sectors !!! Only the first 128 bytes of 512 bytes used
sd_block := (drive_base[noparse][[/noparse]hdsk_drive+8]) + (hdsk_track * 32) + hdsk_sector
err := sd.writeSDCard(sd_block, @disk_buff, 128) 'write a sector
' CheckError(err)
r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)
CheckError(r)
r := tbp2.active 'activate the bus
CheckError(r)
#endif
'++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
if err
UART.str(string("Error hdisk write "))
DisplayError(err)
DisplayHDiskDTS
io_data := $FF 'Return error code
else
io_data := $00 'Return OK.
'----------------------------------------------------------------------------------------------
#else
sd_block := hdsk_base_block 'Start at first block of first HD
sd_block := sd_block + hdsk_drive * (32 * 2048) 'Skip on to the first block of the selected drive
sd_block := sd_block + (hdsk_track * 32) + hdsk_sector 'Find correct block for the selected track/sector
BYTEMOVE (@disk_buff, @ram_z80 + hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer address in Z80 RAM
err := \disk.writeblock(sd_block, @disk_buff) 'Write the block!
if err
UART.str(string("Error hdisk write "))
DisplayError(err)
DisplayHDiskDTS
io_data := $FF 'Return error code
else
io_data := $00 'Return OK.
#endif
'----------------------------------------------------------------------------------------------
hdsk_last_command := hdskNull 'Command completed
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
How come the N8VEM does not use genuine CP/M 2 sources from Digital Research ?
For the auto exec if you look in our CCP.MAC you will find a buffer labelled combuf currently initialized with 16 spaces and the DR copyright message.
Just replace 12 of those spaces with "DO AUTOEXEC" followed by zero and set comlen to 12.
I just did this here by having zicog_demo poke the command into the CCP in HUB RAM prior to starting the emulation, works a treat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Guess I am late to the game but have been following the threads for quite some time and have chatted with Cluso off and on. I will try to get the latest code up today or tomorrow. Will be multitasking between triblade and N8VEM as I want to get uSD working on propIO. I think the tasks are very similar and have a lot in common and I am hoping we can make the SDs interchangeable between the two systems.
Just a few questions / comments. Do we really want a ramdisk?? Before James comes through the wire and chokes me, I think what we really want is a 2 level store going back to the old terminology. We want programs and data that are used often (like editors, compilers, etc) to be available quickly and stuff we really care about to be persisted to permanent storage. As I remember and maybe I am confusing this with one of the many operating systems I have used, that CPM3 and MPM allowed you to mark programs that you want to stay in the banked memory so you could get quick access. If this is true, then I think we want to focus on banked memory that runs efficiently and sacrifice ramdisk and let the OS do that for us under the covers.
The other thing that I remember that there is a trade off in performance and memory when you use large hard disks. I think it was in Johnson-Laird that said you want some small drives for efficient use and large drives for keeping everything. With large drives the directory starts to become unmanageable by the OS as well as the user because CPM and MPM don't support directories. User areas help a little but still can be quite wieldy.
We should make the interchangeability of SD between ZiCog and N8VEM a "must have" high priority requirement. I for one am looking forward to having an N8VEM and PropIO of my own. As I said before I pine for a real Z80. Anyway it makes in easier to exchange stuff between groups in the long run.
Do we want a RAM disk? Well at the moment we have 1MB of RAM at our disposal on the TriBlade. I'm not sure how many banks CP/M 3 can support but just now we are looking at 5 banks of 48K and 12K resident RAM. That's 256K. So what to do with the other 768K? Might as well use it as a RAM disk.
Do you know the upper limit on banked memory in CP/M 3 ?
I have never heard of the ability to "fix" programs into memory but if it exists in CP/M 3 and we can bump up the banked memory then perhaps that changes the priorities of RAM usage. Still implementing a RAM disk is fairly easy on the TriBlade and if we can make it somehow optional or user configurable it may as well be included.
It did occur to me that many smaller hard drives maybe better than a few huge ones, as you say there are no directories to organize things into.
We have the luxury now of many drives as opposed to original CP/M machines where 2 floppies and a hard drive were about the best you could hope for[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A RamDisk should be optional on the TriBlade or whatever hardware. The user can decide how to use. With 4 hard drives, it must be one of them as this is sooo much faster with DMA. Originally I mis-understood what DMA was (thought it was happening in the background) but it just copies the whole sector straight into the cpm disk buffer, not via a temp buffer and then pass each byte individually to cpm. This makes it so much faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Sleep and now at work. Catching up on all the threads. Won't be able to try any code for another 10 hours.
@heater How come the N8VEM does not use genuine CP/M 2 sources from Digital Research ?
For the auto exec if you look in our CCP.MAC you will find a buffer labelled combuf currently initialized with 16 spaces and the DR copyright message.
Just replace 12 of those spaces with "DO AUTOEXEC" followed by zero and set comlen to 12.
I just did this here by having zicog_demo poke the command into the CCP in HUB RAM prior to starting the emulation, works a treat.
I just discovered something - 'DO' and 'SUPERSUB' are actually the same program.
So you can use either. I wonder about a little subroutine in the spin code - in fact three subroutines - POKE, PEEK and POKESTRING. You could then set up an autoexec with one 'pokestring' call and then one poke call for the number of bytes.
Then you don't need to alter the sources so it is still simh compatible. Just use an ifdef to do the pokes if needed.
I don't know about the genuine cp/m sources. Andrew Lynch can probably answer that one.
So we can tick off autorun as being done [noparse]:)[/noparse]
Post Edited (Dr_Acula) : 8/23/2009 12:58:36 AM GMT
Yeah, I noticed that Do emits a SUPERSUB sign on message yesterday. A useful short hand.
I could do the PEEK and POKE on CP/M files sittingin HUB on the DemBoard. It's not so easy on TriBlade where one would have to POKE into the boot sectors in SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re yoda "Do we really want a ramdisk?? Before James comes through the wire and chokes me..."
I'm not sure I necessarily want a ramdisk that loses its memory when you turn it off. But I see it as a stepping stone to a battery backed ram disk. Though it would require some hardware mods as the battery backup chips assume a 5V supply.
What I like about the mini N8VEM is a battery backed ram disk that is as permanent as a sd card, but works much faster. The N8VEM with a battery backed ram boots 20x faster than the zicog (well under 1 second to a A> prompt), and it loads programs 8x faster. MBASIC loads in under half a second.
A non battery backed ram disk will be just as fast, but I guess it is a stepping stone to a battery backed ramdisk. I don't think there is any other storage media that is this fast. Unless... why are sd card reads so slow? I can write an entire 32mb file in about 8 seconds when filling up the card with blank disk images. So *something* is able to talk to an sd card at high speed, ie USB2 speeds. The spin code I've seen is 100khz (maybe 400khz) which is pretty slow actually. Maybe something to explore there.
The SD access is very slow for two reasons. I have tried to explain this many times...
1) The TriBlade code has a bugfix that is emitting a massive amount of useless clocks to force the SD card to release the D0 pin. This is a temporary patch and has a severe overhead.
2) The new driver is much faster - see the fsrw thread by lonesock and rokicki. The driver I am using is an older one from rokicki but it has I2C protocol as well so I need to switch to their new code. It's new and I have not had the time to switch drivers yet. It will deliver a huge improvement.
I have seen more pressing things to do like fixing the missing characters bug (which James has fixed), get CPM3 runing (done), bank switching, and 4 hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re I have seen more pressing things to do like fixing the missing characters bug (which James has fixed), get CPM3 runing (done), bank switching, and 4 hard drives.
all working now?!
Se the other post re musings on speeding things up, though if there are lots of clocks to release a pin... Not sure what that means but if it is slowing things down, that isn't good.
I'm not sure what fsrw is nor which version we are using. There is this code
#ifdef TriBladeProp
cpu : "zicog" 'Zilog Z80 emulator in one COG
UART : "FullDuplexSerial_rr004" 'FDX v1.2 with mods
tbp2 : "TriBladeProp_Blade2_202" 'Blade2 hardware driver
sd : "fsrwFemto" 'SD Software used in FemtoBASIC
#else
cpu : "zicog" 'Zilog Z80 emulator in one COG
disk : "sdspiqasm" 'Low level access to SD card.
UART : "FullDuplexSerial_rr004" 'FDX v1.2 with mods
#endif
The package of files comes with a file fsrwFemto.spin and a file sdspiFemto.spin, both of which access the sd card. The above code references dsspiqasm for access to the sd card. So that is three ways to access an sd card. And now there is a fourth suggestion which is the fast one, right?
What is involved in using this new code. I'm keen to speed this up if at all possible. Can I help in some way?
I have been thinking about the project for some time, and would like to see if I can get CPM up and running using only *off the shelf boards.* (ie demo board and HX512)
and the freely available software AKA Tera Term VT100 emulation software.
There has been a lot of work put into this project, by you guys and it there must be many people who would like to dabble with CPM, but perhaps don't want to commit to TriBladeProp first off. The HK512 Xmem will never compete will TriBladeProp, but its not too bad below 64K, and I am prepared to look at it.
I see heater has written code to copy CMP/2 files to SDcard, but where do I get the CMP/2 files ?
I would be interested to hear you thoughts before I dive in [noparse]:)[/noparse]
BTW Is there an easy way to download this complete thread?
@Ron:
CPM2.2 only uses 64KB of ram so no problems there. We are going to run CPM3 which has banked memory using up to 256KB. Heater would like to run MPM which is also easy. BTW, I have run CPM3 without banked memory many months ago. Any remainder RAM I want to use for a RamDisk with write-through, but this will come later. I see no point in using 128KB memory vs 512KB memory other than the pins used as price is marginal.
We are almost at a point of V1.0 release which will contain all code required to run CPM2.2 including the SD files. All files (code & SD) are contained in the most recent pages of the TriBlade thread.
To copy CPM files to the SD/mciroSD, they are in the latest TriBlade thread. I use windows and have an SD socket in one of my laptops. Otherwise, use a USB adapter. You can use windows to format the card with FAT16 (often just reported as FAT), and use 32KB clusters. Then copy the files posted. This ensures they are contiguous. They are in the correct format.
Ron & others: After discussions with Drac a week ago, I decided the RamBlade should be simple, not complex. It is a cheap way into ZiCog/CPM and other operating systems and uses another prop board as the I/O. Most following this forum have a board which will be compatible to adding the RamBlade to it, although the expansion pins are designed for the Prop ProtoBoard footprint. Price target US$30-40 assembled, availability 2-3 weeks. see the RamBlade thread in my signature)
Postedit: Just posted the latest code on the TriBlade thread. Hopefully we will have a full V1.0 release shortly. A few things to do here first like finish getting the new fsrw code running correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
CP/M will work just fine with 64K of external memory. In fact that is all we have used so far apart from RAM disk testing. We don't have banked memory working yet.
You don't need any special software to copy CP/M disk images to SD any more. Just put them on a newly formatted card as Cluso describes.
Downloading a complete thread would be a neat capability sometimes. No idea how one might do it.
As for the HK512 Xmem. Just a couple of days I ago I was exchanging P.M.s with MikeDiv who also asked about ZiCog on the Hydra and also wants to have a go at getting ZiCog to use that memory card (Even from a Proto Board). Perhaps you two should consult together.
None of us working on ZiCog has a Hydra but I ways thought it world be great if ZiCog ran on it as there must be many of them about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
At this stage I have only looked at Cluso99's memory access functions and made a start writing something for the HX512 card to replace these functions.
It's never going come close Cluso99’s system unless the post increment read/write feature of the HX512K card can be utilized, in some way.
One step at a time, lets see how we go.
It would be great if a thread could be downloaded. This one would is a good read.
Ron, I forget the details but a long time ago I looked at the code required to do random byte accesses on the Hydra memory card. It looked to be like it was a lot of code and would be too slow. The price of the card seemed a bit much for the 64K I could actually use so I did not pursue it further. But as I say many people must have this hardware so support for it would be great.
Now I start to worry that there may not bee enough room in COG to put the Hydra card access code. I forget how many, but we have very few free longs now. I hope we can move things around a bit to accommodate it.
One can download all the pages of a thread using wget under Linux:
Just do it many times changing the page number each time (the p=023 part)
Then it would be nice to be able to strip out all the junk and create a doc with just the posts and attachment links. Someone round here was working on this kind of idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ron & Mike - Unfortunately ZiCog & TriBlade are intermingled between the ZiCog and TriBlade threads, so you will have to read both.
As for the external ram access, there are only 2 sections that have to be changed for alternative accesses. In Zicog, there is one place where ram is read and written. The other is the TriBlade driver which basically is a block ram driver. Both sections should be easy to replace. Don't worry about speed until it works.
Please use a #define to change the code so that we can put it into the mainstream code as yet another option. I will be adding a #define RamBlade as the hardware mapping is different to the TriBlade. As noted above, I posted the latest running code on the TriBlade thread this afternoon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have some code for the HX512K card. Its is incomplete and dirty but it’s posted it just to show how it compares with TriBlade.
Random byte read/writes are as slow as a wet weekend without a Prop.
Having said that, once the address is set, blocks of code can be read or written with post inc/dec. Even a read write word will reduce the bottleneck a little. Read writes of 128 bytes blocks could even be faster than Triblade.
I don’t know how Zicog and CPM handles memory calls, but if there is a lot of random byte access across 128 byte pages I really think it will be too slow.
On the other hand if block transfers can be used (even with some functions) to overcome the poor random access performance of the HX512K , it could still work.
Currently ZiCog uses hub for the buffer between SD and SRAM.
So, for block reads & writes (used in SD disk file access) the TriBlade takes...
A ram read loop to hub write takes 4 instructions plus the wrbyte per loop. This is 32 clock cycles as 8 are wasted because of hub synchronisation.
A ram write loop from hub read takes 8 instructions plus the rdbyte per loop. This is 48 clock cycles as 8 are wasted because of hub synchronisation.
IIRC, a single byte read takes 8 instructions plus the calling overhead. RamBlade will take 4 instructions. A single byte write takes 12 instructions plus the calling overhead. RamBlade will take 8 instructions. Both are Ram to/from COG memory. I have not determined how much faster, if any, the RamBlade will be for block reads and writes.
I have not looked at the Hydra, so I cannot comment on it's access times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
We might just have to accept the fact that it's going to be slower. Given the amount of code that gets trawled through to emulate an op code this slow down may not amount to such a big deal.
More worrying is the size of the code. 66 longs! 23 of them in set_addr_64k. Last time I checked there were only 5 longs free in the ZiCog COG. I hope it's possible to move some more stuff to overlays but there is another speed hit of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ron, I don't think you can have constants larger than 9 bits in pasm.
BUT! there are lots of tricks that can be used to reduce long masks in DAT section, like using ANDN and XOR.
Furthermore, if MOVS, MOVD etc do what they seems they should do, it could be down to something similar to the attached code.
Can anyone confirm that MOVD can be used to alter bits 9..17 only, and in OUTA and DIRA registers too?
I ask because at the moment I have Z80 stepping, but HX apparently filled with garbage, while in my previous attempt (on different source tree) I had the opposite, memory dumps correctly and Z80 hanging on startup.
Note that pin are differently arranged, for two reasons: first this way you don't have to shift data and address chunks around, second my proto is fitted with VGA and PS2 and fail to work if using P16..P23 for databus.
This is great, all of a sudden there are lots of HYDRA/HX512K owners stepping into ZiCog. I look forward to getting the fruits of your labours into a ZiCog release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ron: Sorry, I have just realised I missed your code post - I was writing my reply while checking my code. Will take a look a little later - worked all night on RamBlade.
Antoine: Great to have you aboard too Likewise, I will look at your code a little laer. The more hardware ZiCog supports the better for all of us
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
It certainly works as a hard drive.
with parameters
and that is the same as the 8mb ones except dsm_low and dsm_high are different.
Hmm - something is wrong with the variables [noparse][[/noparse]colon]psh and [noparse][[/noparse]colon]phm in this forum. (which I can't display of course with a colon!) Displays correctly when editing but not correctly in the viewing. Just need to watch that with future cut and pastes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
1) off_low and off_high should be zero as we don't want any reserved tracks on a RAM disk. We never boot from RAM disk.
2) drm_low and drm_high might want adjusting a we might not have so many directory entries in 720K as on an 8MB hard drive.
Which probably means changing al0 and al1.
How this all interacts with the other params I don't know.
Thinking about 1) again. Maybe we DO boot from RAM disk if the emulator populates it first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re "james: might you have to format the drive first ?"
My "formatted" drives are simply 32meg images filled with E5. To erase a drive I and start again, I just copy the new blank file over to the sd card, erase the old DRIVE__I.DSK and rename the blank file as DRIVE__I.DSK. So no need for a format program for the moment. One could write one in CP/M but at the current write rate for an sd card, the above process is a lot quicker.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is modified code for placing the ramdisk as drive I: (replaces all hard drives) so boot from A: and format I: (because I do not initialise·the Ram Disk·correctly) and then pip to it and try it. The dpb_0 will have to reflect a reduced size also.
You will need to place a new #define RamHDisk in the top section of the demo.
I am retiring for the night also.
PRI in_hdskport_read | r 'Handle read from hdskport during a disk read command 'This read triggers the actual disk sector transfer 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 '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #ifdef RamHDisk 'read the block from RamDisk (sram) <=== Note could do direct block move sram -> sram sd_block := (hdsk_track * 32) + hdsk_sector 'offset within the RamHDisk err := tbp2.DoCmd("R", @disk_buff, sd_block*128 + disk_offset, 128) #else r := tbp2.idle 'give up the bus CheckError(r) r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD CheckError(r) ' this method relies on the SD file using contiguous sectors !!! Only the first 128 bytes of 512 bytes used sd_block := (drive_base[noparse][[/noparse]hdsk_drive+8]) + (hdsk_track * 32) + hdsk_sector '8x floppies, then 4x hdisks err := sd.readSDCard(sd_block, @disk_buff, 128) 'read a sector ' CheckError(err) r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running) CheckError(r) r := tbp2.active 'activate the bus CheckError(r) #endif '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ if err UART.str(string("Error hdisk read ")) DisplayError(err) DisplayHDiskDTS io_data := $FF 'Return error code else 'write the block out to sram r := tbp2.DoCmd("W", @disk_buff, hdsk_dma, 128) 'Virtual "DMA" the sector into DMA buffer address in SRAM check_error(r) io_data := $00 'Return OK. '---------------------------------------------------------------------------------------------- #else sd_block := hdsk_base_block 'Start at first block of first HD sd_block := sd_block + hdsk_drive * (32 * 2048) 'Skip on to the first block of the selected drive sd_block := sd_block + (hdsk_track * 32) + hdsk_sector 'Find correct block for the selected track/sector err := \disk.readblock(sd_block, @disk_buff ) 'Read the block ! if err UART.str(string("Error hdisk read ")) DisplayError(err) DisplayHDiskDTS io_data := $FF 'Return error code else BYTEMOVE (@ram_z80 + hdsk_dma, @disk_buff, 128) 'Virtual "DMA" the sector into DMA buffer address in Z80 RAM io_data := $00 'Return OK. #endif '---------------------------------------------------------------------------------------------- hdsk_last_command := hdskNull 'Command completed PRI in_hdskport_write | r 'Handle read from hdskport during a disk write command 'This read triggers the actual disk sector transfer 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 'read the block from sram r := tbp2.DoCmd("R", @disk_buff, hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer address from SRAM check_error(r) '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #ifdef RamHDisk 'write the block to RamDisk (sram) <=== Note could do direct block move sram -> sram sd_block := (hdsk_track * 32) + hdsk_sector err := tbp2.DoCmd("W", @disk_buff, sd_block*128 + disk_offset, 128) #else r := tbp2.idle 'give up the bus CheckError(r) r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD CheckError(r) ' this method relies on the SD file using contiguous sectors !!! Only the first 128 bytes of 512 bytes used sd_block := (drive_base[noparse][[/noparse]hdsk_drive+8]) + (hdsk_track * 32) + hdsk_sector err := sd.writeSDCard(sd_block, @disk_buff, 128) 'write a sector ' CheckError(err) r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running) CheckError(r) r := tbp2.active 'activate the bus CheckError(r) #endif '++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ if err UART.str(string("Error hdisk write ")) DisplayError(err) DisplayHDiskDTS io_data := $FF 'Return error code else io_data := $00 'Return OK. '---------------------------------------------------------------------------------------------- #else sd_block := hdsk_base_block 'Start at first block of first HD sd_block := sd_block + hdsk_drive * (32 * 2048) 'Skip on to the first block of the selected drive sd_block := sd_block + (hdsk_track * 32) + hdsk_sector 'Find correct block for the selected track/sector BYTEMOVE (@disk_buff, @ram_z80 + hdsk_dma, 128) 'Virtual "DMA" the sector from DMA buffer address in Z80 RAM err := \disk.writeblock(sd_block, @disk_buff) 'Write the block! if err UART.str(string("Error hdisk write ")) DisplayError(err) DisplayHDiskDTS io_data := $FF 'Return error code else io_data := $00 'Return OK. #endif '---------------------------------------------------------------------------------------------- hdsk_last_command := hdskNull 'Command completed▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
For the auto exec if you look in our CCP.MAC you will find a buffer labelled combuf currently initialized with 16 spaces and the DR copyright message.
Just replace 12 of those spaces with "DO AUTOEXEC" followed by zero and set comlen to 12.
I just did this here by having zicog_demo poke the command into the CCP in HUB RAM prior to starting the emulation, works a treat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Guess I am late to the game but have been following the threads for quite some time and have chatted with Cluso off and on. I will try to get the latest code up today or tomorrow. Will be multitasking between triblade and N8VEM as I want to get uSD working on propIO. I think the tasks are very similar and have a lot in common and I am hoping we can make the SDs interchangeable between the two systems.
Just a few questions / comments. Do we really want a ramdisk?? Before James comes through the wire and chokes me, I think what we really want is a 2 level store going back to the old terminology. We want programs and data that are used often (like editors, compilers, etc) to be available quickly and stuff we really care about to be persisted to permanent storage. As I remember and maybe I am confusing this with one of the many operating systems I have used, that CPM3 and MPM allowed you to mark programs that you want to stay in the banked memory so you could get quick access. If this is true, then I think we want to focus on banked memory that runs efficiently and sacrifice ramdisk and let the OS do that for us under the covers.
The other thing that I remember that there is a trade off in performance and memory when you use large hard disks. I think it was in Johnson-Laird that said you want some small drives for efficient use and large drives for keeping everything. With large drives the directory starts to become unmanageable by the OS as well as the user because CPM and MPM don't support directories. User areas help a little but still can be quite wieldy.
Interested in comments ?
Dave
We should make the interchangeability of SD between ZiCog and N8VEM a "must have" high priority requirement. I for one am looking forward to having an N8VEM and PropIO of my own. As I said before I pine for a real Z80. Anyway it makes in easier to exchange stuff between groups in the long run.
Do we want a RAM disk? Well at the moment we have 1MB of RAM at our disposal on the TriBlade. I'm not sure how many banks CP/M 3 can support but just now we are looking at 5 banks of 48K and 12K resident RAM. That's 256K. So what to do with the other 768K? Might as well use it as a RAM disk.
Do you know the upper limit on banked memory in CP/M 3 ?
I have never heard of the ability to "fix" programs into memory but if it exists in CP/M 3 and we can bump up the banked memory then perhaps that changes the priorities of RAM usage. Still implementing a RAM disk is fairly easy on the TriBlade and if we can make it somehow optional or user configurable it may as well be included.
It did occur to me that many smaller hard drives maybe better than a few huge ones, as you say there are no directories to organize things into.
We have the luxury now of many drives as opposed to original CP/M machines where 2 floppies and a hard drive were about the best you could hope for[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A RamDisk should be optional on the TriBlade or whatever hardware. The user can decide how to use. With 4 hard drives, it must be one of them as this is sooo much faster with DMA. Originally I mis-understood what DMA was (thought it was happening in the background) but it just copies the whole sector straight into the cpm disk buffer, not via a temp buffer and then pass each byte individually to cpm. This makes it so much faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
We can do the same thing with regular drives as well - we don't have to copy to a temporary buffer unless we are using packed sectors?
Dave
@heater How come the N8VEM does not use genuine CP/M 2 sources from Digital Research ?
For the auto exec if you look in our CCP.MAC you will find a buffer labelled combuf currently initialized with 16 spaces and the DR copyright message.
Just replace 12 of those spaces with "DO AUTOEXEC" followed by zero and set comlen to 12.
I just did this here by having zicog_demo poke the command into the CCP in HUB RAM prior to starting the emulation, works a treat.
I just discovered something - 'DO' and 'SUPERSUB' are actually the same program.
So you can use either. I wonder about a little subroutine in the spin code - in fact three subroutines - POKE, PEEK and POKESTRING. You could then set up an autoexec with one 'pokestring' call and then one poke call for the number of bytes.
Then you don't need to alter the sources so it is still simh compatible. Just use an ifdef to do the pokes if needed.
I don't know about the genuine cp/m sources. Andrew Lynch can probably answer that one.
So we can tick off autorun as being done [noparse]:)[/noparse]
Post Edited (Dr_Acula) : 8/23/2009 12:58:36 AM GMT
I could do the PEEK and POKE on CP/M files sittingin HUB on the DemBoard. It's not so easy on TriBlade where one would have to POKE into the boot sectors in SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not sure I necessarily want a ramdisk that loses its memory when you turn it off. But I see it as a stepping stone to a battery backed ram disk. Though it would require some hardware mods as the battery backup chips assume a 5V supply.
What I like about the mini N8VEM is a battery backed ram disk that is as permanent as a sd card, but works much faster. The N8VEM with a battery backed ram boots 20x faster than the zicog (well under 1 second to a A> prompt), and it loads programs 8x faster. MBASIC loads in under half a second.
A non battery backed ram disk will be just as fast, but I guess it is a stepping stone to a battery backed ramdisk. I don't think there is any other storage media that is this fast. Unless... why are sd card reads so slow? I can write an entire 32mb file in about 8 seconds when filling up the card with blank disk images. So *something* is able to talk to an sd card at high speed, ie USB2 speeds. The spin code I've seen is 100khz (maybe 400khz) which is pretty slow actually. Maybe something to explore there.
1) The TriBlade code has a bugfix that is emitting a massive amount of useless clocks to force the SD card to release the D0 pin. This is a temporary patch and has a severe overhead.
2) The new driver is much faster - see the fsrw thread by lonesock and rokicki. The driver I am using is an older one from rokicki but it has I2C protocol as well so I need to switch to their new code. It's new and I have not had the time to switch drivers yet. It will deliver a huge improvement.
I have seen more pressing things to do like fixing the missing characters bug (which James has fixed), get CPM3 runing (done), bank switching, and 4 hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
all working now?!
Se the other post re musings on speeding things up, though if there are lots of clocks to release a pin... Not sure what that means but if it is slowing things down, that isn't good.
I'm not sure what fsrw is nor which version we are using. There is this code
The package of files comes with a file fsrwFemto.spin and a file sdspiFemto.spin, both of which access the sd card. The above code references dsspiqasm for access to the sd card. So that is three ways to access an sd card. And now there is a fourth suggestion which is the fast one, right?
What is involved in using this new code. I'm keen to speed this up if at all possible. Can I help in some way?
Zicog can now read Cuso's floppy 512_CPM2.DSK
Next up the writes, then same for hard drive.
Attached is the python script that converts SIMH floppy disk to ZiCog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How would CPM/2 go with only 64K of Xmem ?
I have been thinking about the project for some time, and would like to see if I can get CPM up and running using only *off the shelf boards.* (ie demo board and HX512)
and the freely available software AKA Tera Term VT100 emulation software.
There has been a lot of work put into this project, by you guys and it there must be many people who would like to dabble with CPM, but perhaps don't want to commit to TriBladeProp first off. The HK512 Xmem will never compete will TriBladeProp, but its not too bad below 64K, and I am prepared to look at it.
I see heater has written code to copy CMP/2 files to SDcard, but where do I get the CMP/2 files ?
I would be interested to hear you thoughts before I dive in [noparse]:)[/noparse]
BTW Is there an easy way to download this complete thread?
CPM2.2 only uses 64KB of ram so no problems there. We are going to run CPM3 which has banked memory using up to 256KB. Heater would like to run MPM which is also easy. BTW, I have run CPM3 without banked memory many months ago. Any remainder RAM I want to use for a RamDisk with write-through, but this will come later. I see no point in using 128KB memory vs 512KB memory other than the pins used as price is marginal.
We are almost at a point of V1.0 release which will contain all code required to run CPM2.2 including the SD files. All files (code & SD) are contained in the most recent pages of the TriBlade thread.
To copy CPM files to the SD/mciroSD, they are in the latest TriBlade thread. I use windows and have an SD socket in one of my laptops. Otherwise, use a USB adapter. You can use windows to format the card with FAT16 (often just reported as FAT), and use 32KB clusters. Then copy the files posted. This ensures they are contiguous. They are in the correct format.
Ron & others: After discussions with Drac a week ago, I decided the RamBlade should be simple, not complex. It is a cheap way into ZiCog/CPM and other operating systems and uses another prop board as the I/O. Most following this forum have a board which will be compatible to adding the RamBlade to it, although the expansion pins are designed for the Prop ProtoBoard footprint. Price target US$30-40 assembled, availability 2-3 weeks. see the RamBlade thread in my signature)
Postedit: Just posted the latest code on the TriBlade thread. Hopefully we will have a full V1.0 release shortly. A few things to do here first like finish getting the new fsrw code running correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 10/19/2009 5:20:37 AM GMT
CP/M will work just fine with 64K of external memory. In fact that is all we have used so far apart from RAM disk testing. We don't have banked memory working yet.
You don't need any special software to copy CP/M disk images to SD any more. Just put them on a newly formatted card as Cluso describes.
Downloading a complete thread would be a neat capability sometimes. No idea how one might do it.
As for the HK512 Xmem. Just a couple of days I ago I was exchanging P.M.s with MikeDiv who also asked about ZiCog on the Hydra and also wants to have a go at getting ZiCog to use that memory card (Even from a Proto Board). Perhaps you two should consult together.
None of us working on ZiCog has a Hydra but I ways thought it world be great if ZiCog ran on it as there must be many of them about.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
At this stage I have only looked at Cluso99's memory access functions and made a start writing something for the HX512 card to replace these functions.
It's never going come close Cluso99’s system unless the post increment read/write feature of the HX512K card can be utilized, in some way.
One step at a time, lets see how we go.
It would be great if a thread could be downloaded. This one would is a good read.
Ron
Now I start to worry that there may not bee enough room in COG to put the Hydra card access code. I forget how many, but we have very few free longs now. I hope we can move things around a bit to accommodate it.
One can download all the pages of a thread using wget under Linux:
$wget http://forums.parallax.com/forums/default.aspx?f=25&p=023&m=332138
Just do it many times changing the page number each time (the p=023 part)
Then it would be nice to be able to strip out all the junk and create a doc with just the posts and attachment links. Someone round here was working on this kind of idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As for the external ram access, there are only 2 sections that have to be changed for alternative accesses. In Zicog, there is one place where ram is read and written. The other is the TriBlade driver which basically is a block ram driver. Both sections should be easy to replace. Don't worry about speed until it works.
Please use a #define to change the code so that we can put it into the mainstream code as yet another option. I will be adding a #define RamBlade as the hardware mapping is different to the TriBlade. As noted above, I posted the latest running code on the TriBlade thread this afternoon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I have some code for the HX512K card. Its is incomplete and dirty but it’s posted it just to show how it compares with TriBlade.
Random byte read/writes are as slow as a wet weekend without a Prop.
Having said that, once the address is set, blocks of code can be read or written with post inc/dec. Even a read write word will reduce the bottleneck a little. Read writes of 128 bytes blocks could even be faster than Triblade.
I don’t know how Zicog and CPM handles memory calls, but if there is a lot of random byte access across 128 byte pages I really think it will be too slow.
On the other hand if block transfers can be used (even with some functions) to overcome the poor random access performance of the HX512K , it could still work.
Ron
So, for block reads & writes (used in SD disk file access) the TriBlade takes...
A ram read loop to hub write takes 4 instructions plus the wrbyte per loop. This is 32 clock cycles as 8 are wasted because of hub synchronisation.
A ram write loop from hub read takes 8 instructions plus the rdbyte per loop. This is 48 clock cycles as 8 are wasted because of hub synchronisation.
IIRC, a single byte read takes 8 instructions plus the calling overhead. RamBlade will take 4 instructions. A single byte write takes 12 instructions plus the calling overhead. RamBlade will take 8 instructions. Both are Ram to/from COG memory. I have not determined how much faster, if any, the RamBlade will be for block reads and writes.
I have not looked at the Hydra, so I cannot comment on it's access times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
More worrying is the size of the code. 66 longs! 23 of them in set_addr_64k. Last time I checked there were only 5 longs free in the ZiCog COG. I hope it's possible to move some more stuff to overlays but there is another speed hit of course.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BUT! there are lots of tricks that can be used to reduce long masks in DAT section, like using ANDN and XOR.
Furthermore, if MOVS, MOVD etc do what they seems they should do, it could be down to something similar to the attached code.
Can anyone confirm that MOVD can be used to alter bits 9..17 only, and in OUTA and DIRA registers too?
I ask because at the moment I have Z80 stepping, but HX apparently filled with garbage, while in my previous attempt (on different source tree) I had the opposite, memory dumps correctly and Z80 hanging on startup.
Note that pin are differently arranged, for two reasons: first this way you don't have to shift data and address chunks around, second my proto is fitted with VGA and PS2 and fail to work if using P16..P23 for databus.
Ciao
Alessandro
This is great, all of a sudden there are lots of HYDRA/HX512K owners stepping into ZiCog. I look forward to getting the fruits of your labours into a ZiCog release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Antoine: Great to have you aboard too
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm