codefetch long 0
coder long 0
dataread long 0
datar long 0
datawrite long 0
dataw long 0
' When ZiCog wants to read an instruction from 'zpc', it does the following:
cfl rdlong code, coder wz
if_z jmp #cfl ' when NOP (0) read, reader returns $1000_0000
' When ZiCog wants to read the byte at (HL)
drl rdlong acc, datar wz
if_z jmp #drl ' when zero data byte read, returns $1000_0000
' when ZiCog wants to write (HL)
wrlong dataw, acc
wrlong datawrite, HL
mikediv: Brave man. I still don't know anything much about the Hydra RAM expansion. I suspect it takes more PASM code to drive it than will fit in the COG with the Z80 emulation.
Not sure, so if I were attempting it my approach would be to forget about VGA and keyboard and such. Just get a PASM program reading and writing bytes from the external RAM, random access, first. Then you know exactly how many longs you need to do that and can see if it will fit into zicog.
If it fits then move on to getting emulation and CP/M running using the Prop Plug or whatever link back to the PC as a serial terminal interface. Use the terminal emulator in BST.
If that ever gets working then worry about how we are going to do peripherals, keyboard and VGA.
It's a long road....
Heater when you say get the it to read and write ram do you mean the prop ram or the external memory, And you are correct the Hydra 512K ram card is kind of unique in my opinion anyway, becuase like I said the biggest problem for me anyway is I can not use the SD card at the same time one of the other so I have the CPM files on SD and you need more memory that the props 32K so if I could load the CPM files and have the 512K of ram I could do somehting I also tried loading the CPM files to the Hydras big 1 Meg eeprom but its not enough room
to hold the CPM files and then I hit that darn 32K anyway so if I use the upper eeprom as asset I cant address it. Heater you and Clusso are kind of memory gurus for the prop in order to get around the props 32K limitations and say connect a 64 Sram and have it addressed continuously we would need a whole prop OS wouldn't we? DR_A Toby feel free to jump in I understand how to interface Sram to a MCU or CPU to be honest its actually easy what I don't understand fully is why it has to be so hard with a prop I don't fully understand why the 32K limit is it becuase of the prop itself or the IDE?
Actually the more I think about this ,, Bill, Clusso, Heater, DR_A all you guys have successfully added Ram to the prop can anyone just give me a quick Vtech on my above question.
Re decoupling zicog and ram. The problem with the dracblade is no spare cogs. 1 for the interpreter, 1 keyboard, 2 vga, 1 serial, 1 zicog, 1 ram latch, 1 sd card. But it is an intriguing possibility, especially since once you have sent up ram latches is it much quicker to get the second, third byte etc. Mathematically, what is the optimum number of bytes to prefetch? And I guess you need some management code to do that prefetching. On the dracblade, everything is a compromise and I think that code would max out the hub ram (until cluso does the clever code he is working on...). But for the zicog on another emulation, it would be a very useful concept.
What we really need is a way for BST or whatever compiler to emit the PASM sections into separate files that could then be written to SD card. Then when it comes to starting a PASM COG we would read the PASM from SD card file into a big (2K) general purpose buffer and start the COG with it.
Ah, a post from Brad! Brad has a Compiler. This could be very useful. All the models I've been considering all involve cog programs that are relocatable anywhere in memory. Hence you can't referance any locations in hub by name - unless those locations happen to be fixed eg in high ram. This entails a complete rewrite of most objects because most objects have references to hub locations scattered randomly all through the code. Which is no surprise really.
But I wonder if a compiler could be modified to handle this? Consider:
... cog code
.. ?FIT command
The compiler goes through all this one at a time and puts the cog code in where it is meant to and when it is run the coginit moves the cog code into a cog and there is now a pile of wasted bytes in hub ram.