heater: yes, we can go from sd to hub to ram all via pasm. Probably not enough buffer space to go from sd to cog to ram within the one cog, but we will see. Will our sector size remain at 128 or will it go to 512 ??
I have writen my driver to be able to go cog to cog without spin in the middle - it only slows things down tremendously.
Just been tinkering with the microSD - I have copied the files to the SD (Z80 64K and the 448K and 512K files, so I can mod to load from the card. It is still formatted in FAT but I presume we have to ditch this, especially for speed. I cannot believe how quickly I got my microSD working - it was something I thought would take a long time, although I still have to do my own drivers, at least to some extent.
Ale: yes, but unfortunately the jo pays for the hbbbies :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I know what you mean Ale. But I only landed this new gig a few weeks ago after many months of, err, "resting" as they say in the acting profession.
Anyway when I mentioned my hobbies, currently Propellers and CP/M, to my new boss he immediately started thinking how we could use them in some future product developments. Propellers that is not CP/M !! So I'm happy, Linux development with perhaps some embedded Propellers on the side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oh I forgot. Someone on the PropAltair thread posted a version of PropAltair that has its CP/M disk image sitting in a normal FAT file system on SD card as a file.
Provided the disk image file is written to a newly formatted SD card it sits there in contiguous sectors. Only needs a little code somewhere to tell what the start block is so that the CP/M disk emulator can find it.
BINGO you can transfer CP/M to the Prop using a normal PC card writer.
I have to look into that some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There seems to be quite a code overhead for the FAT system, although there would be an equivalent one in the BIOS. We just don't want to have both together slowing things down.
Last night I copied my 1MB image file to the microSD card (using FAT) on the PC. My laptop has an SD slot and I have a SD/microSD converter. However, I don't know how I would do this without FAT on the PC. I guess I would have to do this in spin??
Am I reading your comment above correctly... A newly formatted drive could be created with say 4 10MB (blank data) files called A, B, C, D (drives) and directly access the data (read and write) for these as 4 drives once the start address for each was known ???? I expect the 10MB would need to be 40MB because we will only use the first 128 bytes of each 512 byte sector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes there is overhead in FAT in both code space and time so I never wanted to use it. And besides we have our own CP/M Disk Operating System here. But now with the CP/M RAM space no longer in HUB we can afford to have the FAT code there if we want.
I don't know how to do this under Windows but Linux has the "dd" command that will write bytes from files directly to a drive, sector by sector regardless of file system. Using dd one could just dump the disk CP/M disk image file onto the card with no FAT present.
To get all 8 drive images onto the card just concatenate the files first.
Anyway doing it with a FAT file system on the card would be more convenient for most. So the trick is this. Format a SD card and then write your disk image or images to it. These need not be blank image. For example A.img might be the normal boot disk and B.img might be the WordStar disk. Because they are the first files written to the card, or at least because nothing has ever been deleted from the card, the FAT system is not fragmented and the files sit there in contiguous sectors. They only occupy as much space as the size they are, no wastage. Do this for all 8 drives in 8 files it you like, plus as many hard drives as you want.
Now on the Prop a little bit of code searches for those files on disk and notes the start sector of each. Those start sector numbers are fed into the disk emulation and away we go. As a bonus one can also use the FAT system on the Prop. just don't go deleting the disk images.
On the ProAltair thread is a modified PropAltair that does exactly this for just the A: disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you use external RAM for CP/M then you have enough HubRAM free, to include also the FSRW file system, not only the low level access routines.
Then you can write 128 byte blocks with a FAT file system, instead of raw 512 byte sectors. -> no overhead -> not necessary to find out the startsector.
Cluso
Are you sure that the transfer with PropTerminal not works?
1) After the Fileselect Dialog opens, you must select the right file relativly fast (<30 seconds).
2) Then the download dures several minutes, and you see the first block of the progress bar after perhaps 2 minutes.
Andy
EDIT: Thinked twice, the idea with the 128 byte blocks will not work, because the fsrw has no fast SEEK command. Using 512 byte sectors is much faster. But I still would include a modified fsrw to determine the startsector of the disk files.
Ariba: I had a quite a few bugs, including the introduced ones as I started to try and find the source of the problem. But one thing that seemed to be happening (because I wrote a simple spin program to output what was seen from PropTerminal) is that it seemed to be outputting mouse movements. Removing my external mouse but leaving the laptop pad (whatever it is called) heavilly reduced the extra characters, but not completely. I had to transfer 1MBytes cleanly. Now I have my microSD working I am past that requirement - should have done this first as it was dead easy and I could have loaded from the SD instead of the PC.
AFAIK the SD uses 512 byte blocks, so there is not much use in anything else. Anyway, we have plenty of space so I am just going to waste the 384 bytes and just map 1 CPM 128 byte sector to each 512 byte SD sector.
Now we have at least 20KB free of hub memory - and cogs to burn.
I have discussed with OBC about the FAT and the SD routines he published. I think I am going to start this way, just making a large file first for each of the CPM drives. Then just a binary to start ZiCog from PropDos. If the CPM disks just live inside a FAT file (contiguous) then we should have the best of both worlds.
Anyone have a suggestion about how large the CPM drives should be? And is there a maximum? (I'll have a quick look on the web for this)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
CPM maximum disk size is 8MB and sector size 128 bytes. So I have created a blank (hex $00)·32MB file to be used as a disk drives. We will only be using the first 128 bytes of each 512 byte sector. (posted below in .rar 'zipped' format)
Also, I have created a 1MB file with the 64KB Z80 RAM followed by the 960KB Ram Disk. This is·to be loaded into the 1MB (2x512KB) SRAMs. It packs 4 x 128 byte sectors into the·512 byte sectors on the microSD card since it is just for reading into SRAM. It has the extra 3+6 bytes removed from the altair 137 byte sectors. (posted below in rar 'zipped' format)
For the microSD, I reformatted in FAT16 using 16KB block size. Then I copied the blank files (naming them DRIVE__A.CPM through to DRIVE__H.CPM). Then I copied the DRIVE_1M.RAM file. Hopefully they are contiguous and I can get the data directly without having to use FAT once I know where the files are. I also have a DRIV_CTR.CPM which is just a CPM file with the sector numbers at the beginning of each sector so I can test that I am actually reading the correctly.
Now I am·working on getting the SD loader integrated into ZiCog and/or my hardware driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
After some fight I·got Hydra HX512 SRAM working with the proto board, and then tried to adapt zicog 64k to work with it.
Unfortunately, even reduced at minimum, access to HX512 is some·longs too much to fit in zicog cpu... DAA had to die·
Right now I have a correct dump of external memory map before starting the cpu emulation, the two jumps on lower RAM and all CCP/BIOS/DISKBOOT/etc stuff on top of 64k.
But the emulator hangs, and since I also had to comment out·some other bits (referring to 3propblade vars) inside I/O instruction code,·I'm wondering if I broke something at this step.
Using HX512 with proto board·vs Hydra has the advantage that the reset line can be controlled, so theoretically the inc/dec program could be changed on the fly for special purpose loops.
While the rest is not quite ready for prime time, I'm posting the spin functions that I'm using to load and read back external mem prior to emulation start, just in case anyone is interested in hooking Hydra SRAM to Proto or other propeller platform·(sorry, maybe it's off topic here...)
Thanks to heater, cluso and all the other people involved for their great work.
AntoineDoinel, Welcome to the forum and welcome to ZiCog.
I applaud your effort in trying to use the Hydra expansion RAM with ZiCog. A long time ago I looked at that card to see if I could use it with the Z80 emulation. My conclusion at the time was that 1) It was too expensive for what it offered and 2) It was going to take to much code space to drive it.. 3) The access would be slow.
Whilst it may be a bit pricey that would not necessarily stop me but at the time I sure did not have enough space for the code.
With the new ZiCog code it may be possible to move some more code into overlays such that you can fit the access code in. I will not be looking at this any time soon, first I want to be sure the emulation is as accurate as I can make it..
So please don't give up on this idea, presumably if you can get the access code working for that card then we will also have a ZiCog that runs on the Hydra which many people seem to have.
Remind me about this when we have a perfect emulator and have it running on Cluso's TriBlade properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here's the asm bits used to access the external RAM from cpu module:
'Memory Access Functions
'RAM_P_DBUS long %00000000_00000000_00000000_11111111
RAM_N_DBUS long %11111111_11111111_11111111_00000000
RAM_P_MCLK long %00000000_00000000_00000100_00000000
RAM_N_MCLK long %11111111_11111111_11111011_11111111
RAM_CMD_WR long %11111111_11111111_11111100_11111111 'applied with AND / any start condition
'RAM_CMD_RD long %00000000_00000000_00000001_00000000 'applied with OR / need cookie cut with WR
RAM_CMD_AH long %00000000_00000000_00000011_00000000 'applied with OR / any start condition
RAM_CMD_AL long %11111111_11111111_11111110_11111111 'applied with AND / need AH first
_put_byte_dbus and data_8, #$FF 'mask data
or dira,#RAM_P_DBUS 'DBUS => output
and outa, RAM_N_DBUS 'make hole
or outa, data_8 'write DBUS
or outa, RAM_P_MCLK 'CLK=1
and outa, RAM_N_MCLK 'CLK=0
_put_byte_dbus_ret ret
_get_byte_dbus and dira, RAM_N_DBUS 'DBUS => input
or outa, RAM_P_MCLK 'CLK=1
mov data_8, ina 'read DBUS
and outa, RAM_N_MCLK 'CLK=0
and data_8, #$FF 'mask data
_get_byte_dbus_ret ret
_set_address mov data_8, address
shr data_8, #8
or outa, RAM_CMD_AH
call #_put_byte_dbus
mov data_8, address
and outa, RAM_CMD_AL
call #_put_byte_dbus
_set_address_ret ret
'Read a BYTE from location given by "address" of Z80 RAM into byte data_8
read_memory_byte call #_set_address
and outa, RAM_CMD_WR
or outa,#RAM_CMD_RD
call #_get_byte_dbus
read_memory_byte_ret ret
'Write the BYTE data_8 to location given by "address"
write_memory_byte call #_set_address
and outa, RAM_CMD_WR
call #_put_byte_dbus
write_memory_byte_ret ret
It's assumed that the card is already initialized (by spin helpers in the previous post), also the two·mask values·that fit in·a constant are disabled to save two longs
As you can see it's much slower than necessary (many calls) to save space. I don't know if the original driver could be a better option, but apart from consuming one cog, that command/response IPC stuff scares the hell out of a newbie like me
Regarding HX512 speed, I've also done some experiments with Lattice tools to understand if a firmware better suited for cpu emulation could be developed. I know there's an extended CPLD firmware somewhere in the forum, but that's mostly useful for accessing the area over the lower 64K, not much for emulation.
Essentially the problem is that the card is optimized for pure sequential access. This could be okay for opcode fetches, but accessing data render the internal auto-incrementing counter almost useless, you end using it merely as a not-so-fast latch. I'm sure Andre had low retail price as a priority, still is such a shame that the CPLD is so small, the 4128V and 4256V are available with almost compatible pinout... maybe in rev.2
I did a search for MP/M banking and found out that it's much simpler than say, Coco3 remapper or SWTPC DAT. So I tried to mod the HX512 firmware to squeeze 2x 16-bit counters and 2x 3-bit bank registers: one counter for fetches (so·only needs update·on jumps) and the other for data.
Access to first, second and third 16KB quadrant would go thru first banking register, while fourth quadrant would normally stay at a fixed address (bank=%111) to access ROM and shared RAM, while still allowing to be changed to "recover" the 16KB chunks on the other banks (which apparently get wasted in MP/M banking design, maybe somebody can confirm this).
It compiles and the fitter reports success, but I can not test it soon as I'd like to for lack of free time and also yet have to build a parallel JTAG cable for the CPLD.
This is all most exciting. If formatting a blank sd card and then writing a 1 (or 8) Mb disk image results in contiguous data, then it makes things a lot easier to read. And 8Mb would be more than enough.
I've just got online and bought a sd card, a little USB reader/writer ($5 including shipping?!), and an adaptor card from futurlec so it comes out with a SIL header. I've got to get this going so I can contribute more!
As a general comment, the standard way of doing things for many years has been to put programs in an eprom. An SD card is about the same price as a big eprom. But an SD card reader/writer is considerably cheaper than an eprom programmer plus UV eraser.
Re speed, even if reads and writes to the SD card are slow, you can always PIP programs over to a ramdisk and run them from there. Copy over the ones that you use a lot.
Unfortunately I don't know anything about the hydra so I cannot help there.
Do you have an SD interface? If so that will ultimately help a lot. I am hoping to host the CPM disks under FAT16 as it means it can coexist with PropDos or PropCMD. That way we can boot any prop application including ZiCog.
While ultimately the hardware will be different, the methods can be similar. I have created an external pasm driver, initially for ram disk and loading the Z80 64KB code. I will be extending this to do SD (microSD) for disk access and also for the Z80 block moves as I know this will be much faster.
As we get further into the code we will have to change compilers to do conditional compilation because of differing hardware. I am concentrating on v0.5 of ZiCog currently.
If you want to discuss anything online I am often on msn. PM me for my msn info. I am also trying the IRC (via OBC).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Richard Haseman over at the N8VEM forum has just posted this "I have found some z80 machine code that implements FAT16 and
supports both MMC and SD cards over a SPI interface. I do know that this code
has been successfully used on a couple of Z80 projects so I believe it
will work. The author suggests that the code could be improved - I
just don't know Z80 assembly well enough yet to make those kinds of
improvements. I think this would be a good starting point to
implement a SD card interface using the Z80 to drive the SPI
interface."
He is going to put the code up on the discussion group - it isn't there yet but hopefully in the next 24h. Or maybe it is out there somewhere on the web. Nice to know it has been done and even better if it can be utilised.
Thanks James. Better (faster) to implement it natively on the prop for the ZiCog application, at least for now anyway. Certainly a nice concept and would replace whatever method is used now. Currently I have the fsrwFemto implementation of FAT16 running to read my 64KB Ram and 960KB ram disk in within ZiCog bootup.
I have the Femto SD SPI driver working but I have an issue that the SD does not release the DI/DO (most likely the DO) bus when it's deselected, causing an SRAM conflict which I can overcome by doing dummy reads to the SRAM - it appears to be clocking the SD into a known state before the SD releases DI/DO. Now just have to find a way to get the SD driver to shutdown the SD card properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have barely had time to read the recent posts let alone understand what is going on. When I get a free moment it will be used in perfecting the Z80 op emulation.
Dr_A: Having Z80 FAT16 code will for sure be useful on a real Z80 system. It's not so clear to me what we we would do with it in CP/M on the emulation. More on that later.
AntoineDoinel: You are getting deep into the Hydra RAM card, sadly I know little about it. I think it would be great if we could get ZiCog running on the Hydra with RAM expansion. As I said, at some point if you really need more spcace for the RAM access code I can try and make it. This might have to be a specific Hydra version. Your progress on this would be interesting.
Cluso:
I'm a little confused about what you are up to[noparse]:)[/noparse] With all this talk of 8M disks etc, perhaps I have missed a point some where.
Here is how I thought we were heading:
Currently we have a CP/M BIOS that expects 960K RAM disk as Drive A: it has a special "cluso" disk type defined for that. Then the next 7 drives are normal SIMH AltairZ80 1M drives. It also understands four hard drives of 8MB each.
To make life easy we should use the FAT16 file system on the SD card. Then we can just drop the RAM disk, floppy disk and hard drive images onto it in Windows or Linux. Each image would be a separate file say A.DSK, B.DSK... etc.
These images would be as produced by the SIMH AltairZ80 emulator. This makes it painless to create new disks on Windows or Linux. Yes complete with 137 byte sectors for the RAM and floppy drives (Not the hard drives, they are 128 byte sectors.)
When the SD card gets into the TriBlade the disk emulation will access the appropriate file (Through the FAT16 code) for each drive and use "seek" to find the required sectors. In this way we don't even have to worry about putting the images on newly formatted SD cards in order to get contiguous sectors on the disk.
Given that the Z80 RAM space is now out of the HUB we have space for the FAT code. Now this may slow us down a bit BUT don't worry about that. Our biggest bottle neck at the moment is the byte by byte transfer of data from CP/M BIOS to disk emulation. At some point we implement the block "virtual DMA" transfer and get a all the speed back again (and more I think).
Using the FAT files system in this way has one great advantage. In the SIMH AltairZ80 boot disks there are commands W.COM and R.COM that export and import files from the CP/M file system to/from the underlying operating system's file system. It would be great to be able to do that on the TriBlade as well.
And that, Dr_A, is why Z80 FAT code is not required, we get from CP/M to the FAT system using R and W in a way that is compatible with SIMH AltairZ80.
Hope all this makes sense....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso: I forgot, I have just now set myself up with a new Linux PC and will be doing future work using BSTC and homespun. In emergency I can use the Prop Tool under XP in a virtual machine. (By the way I'm using Sun's VirtualBox to run XP under Linux it's an amazing system).
So now is the time to start using some conditional compilation. Especially since we now have
AntoineDoinel working on the Hydra version and perhaps other variants may also come up.
Perhaps you could post or email a ZiCog.spin version with your latest RAM driver in it and some #ifdefs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Another forgot. Homespun is written in C#. On the homespun wiki page it describes running it under wine on Linux. I've just installed mono on Linux and homespun runs just fine under it:
#mono homespun blabla.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway, here is where I am up to. The microSD (I'll just say SD in future)·is now working after fixing a bug in sdspiFemto.spin to force the SD card·to tristate the D0 when CS is raised. It now functions with the SRAM whereas it was causing a bus conflict.
Currently I am using a FAT16 1GB microSD card and have transferred all files to it from my laptop (it has an SD slot and I have a SD/microSD converter). The files are blank 32MB files which I intend to use as 8MB hard disks for CPM/ZiCog by only using the first 128 byte sectors. I also have a test file 32MB which has the sector number written at the start of each 512 byte sector, once again only using the first 128 bytes for CPM/ZiCog. The next file is a 1MB file which is 4x128 byte sectors per 512 byte sector. It has the first 64KB of the Z80 ram/rom to load into the first 64KB of SRAM (the Z80 code space). The remainder is the 960KB Ram Disk which you sent me, but converted to 128 byte sectors instead of 137 byte sectors. This allows me to load the SRAMup with the whole 1MB image quickly. I now expect to get this running tonight, since I have solved the SD/SRAM bus conflict. Hope this makes sense.
I haven't started using your v0.6 code yet. When I do I will put in the #ifdefs and start using homespun since I don't think bst supports this (BradC - is this correct?)
As soon as I have ZiCog booting again from SRAM via microSD I will post the code (tonight??)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
heater - that all makes sense. And building the image on the altair simh would make things a lot easier. If it runs on the simh, it will run on a real board... Great for debugging etc.
The R and W programs can be batched too. Either by starting the simh and telling it to read input from a batch file rather than from the users keyboard input, or via a telnet connection. I've got both working. To start with though, just use the .dsk images on the simh site.
Keeping them as .dsk files also makes backups simple. Just take the sd card out of the triblade and read back the files to a PC.
I've got a cool simh going with 8 drives with the .dsk files straight off the simh site. No reason this couldn't be emulated:
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
So much seems to be working now. I guess I/O is one thing to think about. On a real board, you use OUT to a port to send a byte to a serial port. You might send a different byte to a different port to change the baud rate. And use IN in a similar way. On the triblade, I presume those IN and OUT statements get captured and sent to the terminal prop? Or to some standard serial prop code? It certainly would be great to have one or two standard serial ports.
Dr_A: Yes, all IO instructions get trapped and handled by the emulator in Spin code. We can add whatever virtual serial ports and peripherals we like there.
However there are no free real IO pins on the Blade #2 running the emulator so everything will have to be piped through the serial connection to the other Blades on the board.
We should try and be compatible with SIMH as much as possible, as you say it will make development much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have DIR and the programs SURVEY and MBASIC running using the SRAM disk loaded from microSD. Its loading under FAT16 but I have disabled writing to the Ram Disk at present. Pics attached
I cannot remember any of MBASIC commands at all - too long ago! Does it require line numbers? Is the print command a "?" I need a quick few lines please.
James: We can communicate to the I/O·blade/prop at speeds approaching 14Mbps using a similar method to Beau's ultra high speed serial between props so I don't see any problems with having multiple uarts on the I/O prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
That has totally made my day. Well done. I think I'm going have a beer to celebrate.
Interesting thing is that SURVEY uses DAA to display those memory statistics. The current implementation is correct, I think, according to the documentation but for sure does not do what a real chip does.
As for MBASIC
A>MBASIC
10 FOR I = 1 TO 10
20 PRINT I
30 NEXT I
RUN
Might do something.
The ultimate test is rebuilding CP/M from sources and installing it to the boot sectors of drive A: Try the submit file SYSCPM2
A>DO SYSCPM2
Do check that MEMCFT.LIB contains the correct definition of msize first:
A>TYPE MEMCFG.LIB
The rebuild process relies on some Z80 ops which hopefully we have working now, LDIR etc.
If it fails is reload RAM disk time [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Not sure if this is any help or if you are already aware of it, but there is a program available for both Linux and Windows that creates an image file of a floppy disk. Raw Write creates a .img file for a 1.44 meg floppy that is 1,474,560 bytes in size. Not sure if this produces the kind of image you are using for this project, but it is probably worth looking at.
I use it for backing up floppies with software for customers instruments I look after and have found it very useful.
There are only five or six more Z80 operations that need to be perfected then ZiCog will be accurate barring the undocumented flag bits.
There are some instructions that the CPU exerciser tests for that don't seem to documented for Zilog or Mostek Z80s. For example operations on the high and low bytes of IX and IY. ZiCog may never support them unless I find a reason to have to. Anyone know about that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I have writen my driver to be able to go cog to cog without spin in the middle - it only slows things down tremendously.
Just been tinkering with the microSD - I have copied the files to the SD (Z80 64K and the 448K and 512K files, so I can mod to load from the card. It is still formatted in FAT but I presume we have to ditch this, especially for speed. I cannot believe how quickly I got my microSD working - it was something I thought would take a long time, although I still have to do my own drivers, at least to some extent.
Ale: yes, but unfortunately the jo pays for the hbbbies :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Anyway when I mentioned my hobbies, currently Propellers and CP/M, to my new boss he immediately started thinking how we could use them in some future product developments. Propellers that is not CP/M !! So I'm happy, Linux development with perhaps some embedded Propellers on the side.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1. SD card/EXT RAM DISK to HUB block buffer.
2. HUB block buffer to CP/Ms DMA buffer. Could be in ext RAM or HUB at the moment.
Back the other way for writes. 1 performed by your SD card/EXT RAM driver in PASM. 2. Is performed by ZiCogs floppy/hard disk emulation also in PASM.
Perhaps all this should be prototyped in SPIN first.
When I have a moment I will look into how to hack the BIOS to do DMA sector transfers in both floppy/hard disk cases and simplify the way it works.
Sector size used by CP/M's BIOS is in all cases 128 bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Provided the disk image file is written to a newly formatted SD card it sits there in contiguous sectors. Only needs a little code somewhere to tell what the start block is so that the CP/M disk emulator can find it.
BINGO you can transfer CP/M to the Prop using a normal PC card writer.
I have to look into that some more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Last night I copied my 1MB image file to the microSD card (using FAT) on the PC. My laptop has an SD slot and I have a SD/microSD converter. However, I don't know how I would do this without FAT on the PC. I guess I would have to do this in spin??
Am I reading your comment above correctly... A newly formatted drive could be created with say 4 10MB (blank data) files called A, B, C, D (drives) and directly access the data (read and write) for these as 4 drives once the start address for each was known ???? I expect the 10MB would need to be 40MB because we will only use the first 128 bytes of each 512 byte sector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I don't know how to do this under Windows but Linux has the "dd" command that will write bytes from files directly to a drive, sector by sector regardless of file system. Using dd one could just dump the disk CP/M disk image file onto the card with no FAT present.
dd if=cpm2.dsk of=/dev/whatever-the-flash-device-is
To get all 8 drive images onto the card just concatenate the files first.
Anyway doing it with a FAT file system on the card would be more convenient for most. So the trick is this. Format a SD card and then write your disk image or images to it. These need not be blank image. For example A.img might be the normal boot disk and B.img might be the WordStar disk. Because they are the first files written to the card, or at least because nothing has ever been deleted from the card, the FAT system is not fragmented and the files sit there in contiguous sectors. They only occupy as much space as the size they are, no wastage. Do this for all 8 drives in 8 files it you like, plus as many hard drives as you want.
Now on the Prop a little bit of code searches for those files on disk and notes the start sector of each. Those start sector numbers are fed into the disk emulation and away we go. As a bonus one can also use the FAT system on the Prop. just don't go deleting the disk images.
On the ProAltair thread is a modified PropAltair that does exactly this for just the A: disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you use external RAM for CP/M then you have enough HubRAM free, to include also the FSRW file system, not only the low level access routines.
Then you can write 128 byte blocks with a FAT file system, instead of raw 512 byte sectors. -> no overhead -> not necessary to find out the startsector.
Cluso
Are you sure that the transfer with PropTerminal not works?
1) After the Fileselect Dialog opens, you must select the right file relativly fast (<30 seconds).
2) Then the download dures several minutes, and you see the first block of the progress bar after perhaps 2 minutes.
Andy
EDIT: Thinked twice, the idea with the 128 byte blocks will not work, because the fsrw has no fast SEEK command. Using 512 byte sectors is much faster. But I still would include a modified fsrw to determine the startsector of the disk files.
Post Edited (Ariba) : 4/1/2009 3:45:18 AM GMT
AFAIK the SD uses 512 byte blocks, so there is not much use in anything else. Anyway, we have plenty of space so I am just going to waste the 384 bytes and just map 1 CPM 128 byte sector to each 512 byte SD sector.
Now we have at least 20KB free of hub memory - and cogs to burn.
I have discussed with OBC about the FAT and the SD routines he published. I think I am going to start this way, just making a large file first for each of the CPM drives. Then just a binary to start ZiCog from PropDos. If the CPM disks just live inside a FAT file (contiguous) then we should have the best of both worlds.
Anyone have a suggestion about how large the CPM drives should be? And is there a maximum? (I'll have a quick look on the web for this)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Also, I have created a 1MB file with the 64KB Z80 RAM followed by the 960KB Ram Disk. This is·to be loaded into the 1MB (2x512KB) SRAMs. It packs 4 x 128 byte sectors into the·512 byte sectors on the microSD card since it is just for reading into SRAM. It has the extra 3+6 bytes removed from the altair 137 byte sectors. (posted below in rar 'zipped' format)
For the microSD, I reformatted in FAT16 using 16KB block size. Then I copied the blank files (naming them DRIVE__A.CPM through to DRIVE__H.CPM). Then I copied the DRIVE_1M.RAM file. Hopefully they are contiguous and I can get the data directly without having to use FAT once I know where the files are. I also have a DRIV_CTR.CPM which is just a CPM file with the sector numbers at the beginning of each sector so I can test that I am actually reading the correctly.
Now I am·working on getting the SD loader integrated into ZiCog and/or my hardware driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
After some fight I·got Hydra HX512 SRAM working with the proto board, and then tried to adapt zicog 64k to work with it.
Unfortunately, even reduced at minimum, access to HX512 is some·longs too much to fit in zicog cpu... DAA had to die·
Right now I have a correct dump of external memory map before starting the cpu emulation, the two jumps on lower RAM and all CCP/BIOS/DISKBOOT/etc stuff on top of 64k.
But the emulator hangs, and since I also had to comment out·some other bits (referring to 3propblade vars) inside I/O instruction code,·I'm wondering if I broke something at this step.
Using HX512 with proto board·vs Hydra has the advantage that the reset line can be controlled, so theoretically the inc/dec program could be changed on the fly for special purpose loops.
While the rest is not quite ready for prime time, I'm posting the spin functions that I'm using to load and read back external mem prior to emulation start, just in case anyone is interested in hooking Hydra SRAM to Proto or other propeller platform·(sorry, maybe it's off topic here...)
Thanks to heater, cluso and all the other people involved for their great work.
I applaud your effort in trying to use the Hydra expansion RAM with ZiCog. A long time ago I looked at that card to see if I could use it with the Z80 emulation. My conclusion at the time was that 1) It was too expensive for what it offered and 2) It was going to take to much code space to drive it.. 3) The access would be slow.
Whilst it may be a bit pricey that would not necessarily stop me but at the time I sure did not have enough space for the code.
With the new ZiCog code it may be possible to move some more code into overlays such that you can fit the access code in. I will not be looking at this any time soon, first I want to be sure the emulation is as accurate as I can make it..
So please don't give up on this idea, presumably if you can get the access code working for that card then we will also have a ZiCog that runs on the Hydra which many people seem to have.
Remind me about this when we have a perfect emulator and have it running on Cluso's TriBlade properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
'Memory Access Functions 'RAM_P_DBUS long %00000000_00000000_00000000_11111111 RAM_N_DBUS long %11111111_11111111_11111111_00000000 RAM_P_MCLK long %00000000_00000000_00000100_00000000 RAM_N_MCLK long %11111111_11111111_11111011_11111111 RAM_CMD_WR long %11111111_11111111_11111100_11111111 'applied with AND / any start condition 'RAM_CMD_RD long %00000000_00000000_00000001_00000000 'applied with OR / need cookie cut with WR RAM_CMD_AH long %00000000_00000000_00000011_00000000 'applied with OR / any start condition RAM_CMD_AL long %11111111_11111111_11111110_11111111 'applied with AND / need AH first _put_byte_dbus and data_8, #$FF 'mask data or dira,#RAM_P_DBUS 'DBUS => output and outa, RAM_N_DBUS 'make hole or outa, data_8 'write DBUS or outa, RAM_P_MCLK 'CLK=1 and outa, RAM_N_MCLK 'CLK=0 _put_byte_dbus_ret ret _get_byte_dbus and dira, RAM_N_DBUS 'DBUS => input or outa, RAM_P_MCLK 'CLK=1 mov data_8, ina 'read DBUS and outa, RAM_N_MCLK 'CLK=0 and data_8, #$FF 'mask data _get_byte_dbus_ret ret _set_address mov data_8, address shr data_8, #8 or outa, RAM_CMD_AH call #_put_byte_dbus mov data_8, address and outa, RAM_CMD_AL call #_put_byte_dbus _set_address_ret ret 'Read a BYTE from location given by "address" of Z80 RAM into byte data_8 read_memory_byte call #_set_address and outa, RAM_CMD_WR or outa,#RAM_CMD_RD call #_get_byte_dbus read_memory_byte_ret ret 'Write the BYTE data_8 to location given by "address" write_memory_byte call #_set_address and outa, RAM_CMD_WR call #_put_byte_dbus write_memory_byte_ret retIt's assumed that the card is already initialized (by spin helpers in the previous post), also the two·mask values·that fit in·a constant are disabled to save two longs
As you can see it's much slower than necessary (many calls) to save space. I don't know if the original driver could be a better option, but apart from consuming one cog, that command/response IPC stuff scares the hell out of a newbie like me
Regarding HX512 speed, I've also done some experiments with Lattice tools to understand if a firmware better suited for cpu emulation could be developed. I know there's an extended CPLD firmware somewhere in the forum, but that's mostly useful for accessing the area over the lower 64K, not much for emulation.
Essentially the problem is that the card is optimized for pure sequential access. This could be okay for opcode fetches, but accessing data render the internal auto-incrementing counter almost useless, you end using it merely as a not-so-fast latch. I'm sure Andre had low retail price as a priority, still is such a shame that the CPLD is so small, the 4128V and 4256V are available with almost compatible pinout... maybe in rev.2
I did a search for MP/M banking and found out that it's much simpler than say, Coco3 remapper or SWTPC DAT. So I tried to mod the HX512 firmware to squeeze 2x 16-bit counters and 2x 3-bit bank registers: one counter for fetches (so·only needs update·on jumps) and the other for data.
Access to first, second and third 16KB quadrant would go thru first banking register, while fourth quadrant would normally stay at a fixed address (bank=%111) to access ROM and shared RAM, while still allowing to be changed to "recover" the 16KB chunks on the other banks (which apparently get wasted in MP/M banking design, maybe somebody can confirm this).
It compiles and the fitter reports success, but I can not test it soon as I'd like to for lack of free time and also yet have to build a parallel JTAG cable for the CPLD.
I hope to post something more meaningful soon.
I've just got online and bought a sd card, a little USB reader/writer ($5 including shipping?!), and an adaptor card from futurlec so it comes out with a SIL header. I've got to get this going so I can contribute more!
As a general comment, the standard way of doing things for many years has been to put programs in an eprom. An SD card is about the same price as a big eprom. But an SD card reader/writer is considerably cheaper than an eprom programmer plus UV eraser.
Re speed, even if reads and writes to the SD card are slow, you can always PIP programs over to a ramdisk and run them from there. Copy over the ones that you use a lot.
Unfortunately I don't know anything about the hydra so I cannot help there.
Do you have an SD interface? If so that will ultimately help a lot. I am hoping to host the CPM disks under FAT16 as it means it can coexist with PropDos or PropCMD. That way we can boot any prop application including ZiCog.
While ultimately the hardware will be different, the methods can be similar. I have created an external pasm driver, initially for ram disk and loading the Z80 64KB code. I will be extending this to do SD (microSD) for disk access and also for the Z80 block moves as I know this will be much faster.
As we get further into the code we will have to change compilers to do conditional compilation because of differing hardware. I am concentrating on v0.5 of ZiCog currently.
If you want to discuss anything online I am often on msn. PM me for my msn info. I am also trying the IRC (via OBC).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
supports both MMC and SD cards over a SPI interface. I do know that this code
has been successfully used on a couple of Z80 projects so I believe it
will work. The author suggests that the code could be improved - I
just don't know Z80 assembly well enough yet to make those kinds of
improvements. I think this would be a good starting point to
implement a SD card interface using the Z80 to drive the SPI
interface."
He is going to put the code up on the discussion group - it isn't there yet but hopefully in the next 24h. Or maybe it is out there somewhere on the web. Nice to know it has been done and even better if it can be utilised.
I have the Femto SD SPI driver working but I have an issue that the SD does not release the DI/DO (most likely the DO) bus when it's deselected, causing an SRAM conflict which I can overcome by doing dummy reads to the SRAM - it appears to be clocking the SD into a known state before the SD releases DI/DO. Now just have to find a way to get the SD driver to shutdown the SD card properly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I have barely had time to read the recent posts let alone understand what is going on. When I get a free moment it will be used in perfecting the Z80 op emulation.
Dr_A: Having Z80 FAT16 code will for sure be useful on a real Z80 system. It's not so clear to me what we we would do with it in CP/M on the emulation. More on that later.
AntoineDoinel: You are getting deep into the Hydra RAM card, sadly I know little about it. I think it would be great if we could get ZiCog running on the Hydra with RAM expansion. As I said, at some point if you really need more spcace for the RAM access code I can try and make it. This might have to be a specific Hydra version. Your progress on this would be interesting.
Cluso:
I'm a little confused about what you are up to[noparse]:)[/noparse] With all this talk of 8M disks etc, perhaps I have missed a point some where.
Here is how I thought we were heading:
Currently we have a CP/M BIOS that expects 960K RAM disk as Drive A: it has a special "cluso" disk type defined for that. Then the next 7 drives are normal SIMH AltairZ80 1M drives. It also understands four hard drives of 8MB each.
To make life easy we should use the FAT16 file system on the SD card. Then we can just drop the RAM disk, floppy disk and hard drive images onto it in Windows or Linux. Each image would be a separate file say A.DSK, B.DSK... etc.
These images would be as produced by the SIMH AltairZ80 emulator. This makes it painless to create new disks on Windows or Linux. Yes complete with 137 byte sectors for the RAM and floppy drives (Not the hard drives, they are 128 byte sectors.)
When the SD card gets into the TriBlade the disk emulation will access the appropriate file (Through the FAT16 code) for each drive and use "seek" to find the required sectors. In this way we don't even have to worry about putting the images on newly formatted SD cards in order to get contiguous sectors on the disk.
Given that the Z80 RAM space is now out of the HUB we have space for the FAT code. Now this may slow us down a bit BUT don't worry about that. Our biggest bottle neck at the moment is the byte by byte transfer of data from CP/M BIOS to disk emulation. At some point we implement the block "virtual DMA" transfer and get a all the speed back again (and more I think).
Using the FAT files system in this way has one great advantage. In the SIMH AltairZ80 boot disks there are commands W.COM and R.COM that export and import files from the CP/M file system to/from the underlying operating system's file system. It would be great to be able to do that on the TriBlade as well.
And that, Dr_A, is why Z80 FAT code is not required, we get from CP/M to the FAT system using R and W in a way that is compatible with SIMH AltairZ80.
Hope all this makes sense....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So now is the time to start using some conditional compilation. Especially since we now have
AntoineDoinel working on the Hydra version and perhaps other variants may also come up.
Perhaps you could post or email a ZiCog.spin version with your latest RAM driver in it and some #ifdefs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
#mono homespun blabla.spin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway, here is where I am up to. The microSD (I'll just say SD in future)·is now working after fixing a bug in sdspiFemto.spin to force the SD card·to tristate the D0 when CS is raised. It now functions with the SRAM whereas it was causing a bus conflict.
Currently I am using a FAT16 1GB microSD card and have transferred all files to it from my laptop (it has an SD slot and I have a SD/microSD converter). The files are blank 32MB files which I intend to use as 8MB hard disks for CPM/ZiCog by only using the first 128 byte sectors. I also have a test file 32MB which has the sector number written at the start of each 512 byte sector, once again only using the first 128 bytes for CPM/ZiCog. The next file is a 1MB file which is 4x128 byte sectors per 512 byte sector. It has the first 64KB of the Z80 ram/rom to load into the first 64KB of SRAM (the Z80 code space). The remainder is the 960KB Ram Disk which you sent me, but converted to 128 byte sectors instead of 137 byte sectors. This allows me to load the SRAMup with the whole 1MB image quickly. I now expect to get this running tonight, since I have solved the SD/SRAM bus conflict. Hope this makes sense.
I haven't started using your v0.6 code yet. When I do I will put in the #ifdefs and start using homespun since I don't think bst supports this (BradC - is this correct?)
As soon as I have ZiCog booting again from SRAM via microSD I will post the code (tonight??)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The R and W programs can be batched too. Either by starting the simh and telling it to read input from a batch file rather than from the users keyboard input, or via a telnet connection. I've got both working. To start with though, just use the .dsk images on the simh site.
Keeping them as .dsk files also makes backups simple. Just take the sd card out of the triblade and read back the files to a PC.
I've got a cool simh going with 8 drives with the .dsk files straight off the simh site. No reason this couldn't be emulated:
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
So much seems to be working now. I guess I/O is one thing to think about. On a real board, you use OUT to a port to send a byte to a serial port. You might send a different byte to a different port to change the baud rate. And use IN in a similar way. On the triblade, I presume those IN and OUT statements get captured and sent to the terminal prop? Or to some standard serial prop code? It certainly would be great to have one or two standard serial ports.
However there are no free real IO pins on the Blade #2 running the emulator so everything will have to be piped through the serial connection to the other Blades on the board.
We should try and be compatible with SIMH as much as possible, as you say it will make development much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have DIR and the programs SURVEY and MBASIC running using the SRAM disk loaded from microSD. Its loading under FAT16 but I have disabled writing to the Ram Disk at present. Pics attached
I cannot remember any of MBASIC commands at all - too long ago! Does it require line numbers? Is the print command a "?" I need a quick few lines please.
James: We can communicate to the I/O·blade/prop at speeds approaching 14Mbps using a similar method to Beau's ultra high speed serial between props so I don't see any problems with having multiple uarts on the I/O prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Interesting thing is that SURVEY uses DAA to display those memory statistics. The current implementation is correct, I think, according to the documentation but for sure does not do what a real chip does.
As for MBASIC
A>MBASIC
10 FOR I = 1 TO 10
20 PRINT I
30 NEXT I
RUN
Might do something.
The ultimate test is rebuilding CP/M from sources and installing it to the boot sectors of drive A: Try the submit file SYSCPM2
A>DO SYSCPM2
Do check that MEMCFT.LIB contains the correct definition of msize first:
A>TYPE MEMCFG.LIB
The rebuild process relies on some Z80 ops which hopefully we have working now, LDIR etc.
If it fails is reload RAM disk time [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Michael, I'll join you in that beer !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I use it for backing up floppies with software for customers instruments I look after and have found it very useful.
THAT'S AWESOME! I'm dying to get my TriBlade built!
Sounds like you guys are very nearly compatible at this point!
How about some Zork screenshots next? [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
There are some instructions that the CPU exerciser tests for that don't seem to documented for Zilog or Mostek Z80s. For example operations on the high and low bytes of IX and IY. ZiCog may never support them unless I find a reason to have to. Anyone know about that?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
No, there shouldn't be. Which irc client are you using? (Still using my webpage?)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.