Attached is a new bootable RAM disk image of 982016 bytes, a tad shy of 960K, with a formatted capacity of 864KB. The next possible size up is a little to big to fit.
To drive it there is a new CBIOSX.COM as well.
Sorry this is sill using 137 byte sectors/blocks. Changing the BIOS to use 128 byte sectors is easy. Trouble is it then requires changes to the SIMH emulator to handle that so that I can test it.
Plan is to make a simple program that translates SIMH Altair disk images into 128 byte/sector images for use on the TriBladeProp both as RAM disks and SD card files. Then make a custom BIOS for the TriBlade to handle these. I can't test this until I get my TriBlade unless Cluso wants to have a go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think it is not nessesary to have it SIMH compatible.
Only zicog for work on it as fast revritable disk.
For Compilatrs, WordStar and simlar programs.
With end of work simply copy it to SD for storage
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Where did the 137 byte thing come from? Sounds a rather odd number.
With the N8VEM the only program the board starts off with is xmodem. Then you use xmodem to transfer over files, which is maybe 10-20 seconds at 38400 baud. The thing about that is that the board saving the data does all the work with sectors and file allocation. So the file could come from the SIMH or anywhere really, and as it comes down the cable it just ends up a stream of bytes and then xmodem and CP/M sort out where those bytes go, ie which track and sector.
I've got a triblade prop board now (thanks Cluso99!), so now I need to get some parts.
As an aside, I've had a N8VEM on the net for the last few days and been testing telnet and bulletin board software with people logging in from the Vintage Computer Forum. There are some issues with file transfer to sort out, but a lot is working and some people have left messages, run programs, run wordstar etc. The Zicog looks like it might be getting close to this stage too. We are using a software bridge on a PC to go from ethernet to serial, but maybe this sort of thing could reside on a prop as well?
Re: "What is the purpose of emulating a processor that's over 30 years old on the prop? " Ah - a good question.
For me, it is a matter of solving a problem. I want to get data from a to b in a remote setting. Real data too - like a jpg photo triggered by an animal walking past. Or the level in a stock trough. Wires don't work - the wildlife chews them and lightening is strangely attracted to them. Buried wires are impractical down a cliff and through rock. Lasers won't work through mist. Radio is the practical answer. You can throw heaps of power at a radio problem but there are licence issue as well as getting the power to a remote setting. Solar costs $50 per watt if you want 24 hour reliability so you need flea power. So I'm working on multiple low power radio transceivers that can automatically find each other and have enough internal intelligence to work out optimum routes for messages. I've built a system using picaxes, but there are always bugs and fixing bugs is hard when you have to hike down a cliff each time to reprogram a board. So this leads to the concept of a board that can compile its own programs on itself, plus send complete files including updates to communication programs. This means some sort of operating system is needed. Plus - you might want to run a batch file on startup, and you might want to edit that batch file, so you need a text editor. CP/M can do all these things and probably represents the simplest operating system that can. Propeller can do most of these things, but not all because it can't recompile programs on itself - you still need a PC. So combining the two gives the best of both worlds.
Oh, and I guess the other reason is because it is a totally nerdy propellerhead sort of thing to do *grin*.
Post Edited (Dr_Acula (James Moxham)) : 3/22/2009 3:11:19 AM GMT
James, thanks for the info on the Vintage Computer Forum - I have registered as "Cluso" there as Cluso99 was used
A number of people have started receiving the TriBladeProp PCBs (UK, USA, Netherlands & Australia) so I will answer questions on the TriBladeProp thread (page 3) http://forums.parallax.com/showthread.php?p=786418
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I guess we don't have to be SIMH compatible in the end. Compatibility has been very convenient to get started with. It's a kind of bootstrap "chicken and egg" problem. Having disk images and BIOSs that one can copy to the Prop and they just work saves having to debug an emulator and a BIOS and all at the same time.
Baggers:
I'd love it if someone wants to take ZiCog and incorporate it into a an Amstrad emulation, or a Sinclar, or whatever. Sure we need accurate Z80 emulation, that is nearly done. Not sure if we will have the speed. But that's just the beginning of the problems though:
1. Amstrads used bank switched memory to get to 256 or 512K RAM. We can add bank switching to ZiCog but it is another speed hit.
2. Amstrad screen could display 90 characters on a line. Can we do that from a Prop with VGA? Not to mention that the video was bit mapped in a very odd way.
3. They did use some funky hardware in some models. Like the "Roller RAM", video hardware etc.
I'd like to find the smallest VGA screen that will display 80 characters per line legibly and build a portable CP/M computer with it and Cluso's TriBlade.
Dr_A:
That 137 bytes comes from the sector size used on old Altair floppy disks, as Sapieha points out.
Kwin:
That's amazing. I would be overjoyed if you have a real world application for all this. Please let us know if you proceed with that. At some point I'm going to create a Intel 8080/85 only version of ZiCog, which will be called iCog. This will be a lot smaller and have 8080 accurate flag settings. Could be useful in recycling code from old 8085 system EPROMs if you really can't or don't want to rewrite that code.
bmb!:
I have no idea why we are doing all this[noparse]:)[/noparse] I go along with the statements of Cluso, Dr_A, Mike etc. and as George Mallory said "Because it's there"
When I started the 8080 emulator, PropAltair, over a year ago it was just as an exercise in learning what tricks one could do with this curious new Propeller chip. Since then it has grown a life of it's own. I never expected that it would attract as much interest as it has. Many people here have helped along the way, especially Cluso who has now developed a great hardware platform for it to live on. At some point I have to write all this up on it's own web pages with full credits to everyone.
I always said I was not going to extend the thing to a full up Z80 emulation. But it just keeps nagging at me.
This has all been a hobby of course, and a great learning exercise. As a result the prop may well find it's way into some new products in my new work place.
If kwin has a real use for the emulator that is icing on the cake.
After that it's back to crossword puzzles or watching TV......no no I can hear that 6809 emulator calling me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not so sure ... If You use Copy from R: RAM dirve to A: else B: SD Drive's·SIHM formated·COPY comand .. It wil stil be SIMH compatible
Ps. Have R: drive only ´for Write intensive work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Yes, I was just tinkering with the BIOS with a mind to do something like that.
1. Add a new RAM disk drive type to the BIOS that uses 128 byte sectors and is small enough to fit in 960K RAM space.
2. Use that RAM disk type for the B: drive. This will still be on SD card on my demo board hardware.
3. Boot up the Propeller ZiCog with the new BIOS and check that it works FORMAT, DIR, PIP etc.
4. COPY the A: drive to the B: drive on SD card.
The B: drive is now our required RAM disk image.
Now how to get that off the SD card which currently is is just a concatenation of CP/M disk images so my PC cannot read it.
Hopefully under Linux I can use the dd command to pull the bytes off the SD card into a file.
Then:
5. Modify the BIOS again to use the new RAM disk type for drive A:
6. Use dd again to copy the SD's B: image to A: (Or a simple spin program)
7. Boot the propeller ZiCog again and check all is OK with the A: drive .
Now Cluso has a RAM disk bootable drive A: image and BIOS to go with it.
On the other hand I might not bother as Cluso squeezing the 137 byte sectors into 128 byte blocks in the RAM disk and faking the spare bytes when presenting them to ZiCog.
Edit: Oops I forgot, the resulting image in the above plan would be 128 byte sectors each sitting in a 512 byte SD card block so we have to remember to get ZiCog to put 4 sectors in a block for the new drive type to get a nice RAM image.
I just noticed that the BIOS we are using detects when it is running on a Z80 and then uses LDIR. Just as well LDIR was one of the first Z80 ops I tested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'd love it if someone wants to take ZiCog and incorporate it into a an Amstrad emulation, or a Sinclar, or whatever. Sure we need accurate Z80 emulation, that is nearly done. Not sure if we will have the speed. But that's just the beginning of the problems though:
1. Amstrads used bank switched memory to get to 256 or 512K RAM. We can add bank switching to ZiCog but it is another speed hit.
2. Amstrad screen could display 90 characters on a line. Can we do that from a Prop with VGA? Not to mention that the video was bit mapped in a very odd way.
3. They did use some funky hardware in some models. Like the "Roller RAM", video hardware etc.
I'd like to find the smallest VGA screen that will display 80 characters per line legibly and build a portable CP/M computer with it and Cluso's TriBlade.
Heater, once I've got my system setup, I'll have a go at making it into a Sinclair machine [noparse]:)[/noparse] although it'll most likely not run full speed, it'll still be a great advance, and once PropII comes along the speed will be there, plentiful [noparse]:)[/noparse]
heater,
I was thinking since we have more RAM, to do a Spectrum [noparse]:D[/noparse] as the spectrum would be the easier of the two to emulate as the ZX81 has to do some screen display stuff.
And yes, I have the ROM images.
Once I solve the problem of reading the code from the PC via PropTerminal (I have a bug/s!), I can manipulate the bytes/sector within spin and write to the SRAM in the pasm routine. At the moment all disk activity in the ZiCog goes via a spin cog, but I see later that being cog to cog pasm via hub command directly. I see the SRAM disk cog also handling the microSD also. So the only thing that CPM will need to know is how big a particular disk is.
I would think an 8088 emulation might be a good idea later on. That way we could run DRDOS, Turbo Pascal, etc. We have enough RAM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The microSD is not running yet. I thought it would be easier to get the SRAM working first but found some problems in loading it from the PC. Thik I have found the problem - my pasm code is too fast - I have placed a delay and it seems to be doing something now - separate standalone test code.
The obvious ultimate goal is to load either from microSD or Flash.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Finally discovered my bug in reading a file from the PC - dreaded space in the pathname :-(
Testing on the 137 byte sectors indicates that the first 3 bytes are $A7 $OE $D2 and the last 6 are $B7 $C8 $CD $A5 $2B $00.
So I will base my RAM Disk on 128 byte sectors and return the constants to make the buffer look like the 137 byte sector. This doesn't waste the space and makes the pasm code easier (no maths).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Those leading and trailing bytes agree with my hexdump of RAM.DSK so it looks like we are good to go. Not sure why or how they have those values and I'm sure the BIOS does not care what they are. But nice to have for "completeness" as it were.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater--
>BrainDamage!!! Is that Leor "BrainDamage" Zolman. If so I am honoured that you should turn up here on this thread.
Good ole' Google....but evidently it takes a while sometimes for board posts to make their way into the database...
>I always assumed BDS C restricted itself to 8080 instructions. Those simple tests I have done with it on the Prop emulation work just fine. But they do not use such things as memcmp or strcpy. For sure I want to get all the flags right in ZiCog so that this works as you say.
I took a look at Z80 opcodes early on and decided there was little or no advantage to using them in the generated code; too convoluted. I really couldn't improve on the basic fetching/storing and calculation operations by using Z80 ops, so what was the point... however, internally, BDS C does a lot of block moves during compilation because it's shifting stuff up and down in memory dynamically. Since the Z80 block moves do run faster than unwound 8080 loops, I took advantage of that one feature only. So the first compiler module (cc) does it (by checking the parity flag behavior) in the block move section, and I *believe* the block move library function(s) [noparse][[/noparse]I can't even recall how many there were] also make the check.
Heater: I have loaded the ram.dsk into SRAM. I have read the first 2 sectors back and displayed them. Here is a pic of the screen. I presume a DIR should display files, so obviously something is not quite right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OK here is a very simple test. I modified dskread to display the first 256 bytes delivered to to CP/M from disk as below. With results in the attached image.
PRI in_dskread
'Handle reads from the floppy disk read data port
if altair_bidx == 0
'Read a new block from SD card
sd_block := (altair_drive * tracks * 32) + (altair_track[noparse][[/noparse]altair_drive] * 32) + altair_sector
err := \disk.readblock(sd_block, @disk_buff)
io_data := disk_buff[noparse][[/noparse]altair_bidx]
if dbgcnt++ < 521
'TV.str(string("HL="))
TV.hex(io_data, 2)
TV.out(" ")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater. I am seeing different data. The first sector read is 00000C. I am using the latest ram.dsk that you posted above. The forst few sectors have either all zeros or all E5's. Any ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I now have the ZiCog using 64KBytes of SRAM for the code and 960KBytes of SRAM Disk. It can now (finally) do a DIR command.
I have posted the code but it is a bit rough with debug code throughout. Also a pic of the screen. It uses my new TriBladeProp·Blade #2 driver routine that I published on the TriBladeProp thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Clusso, this is great. Can you run SURVEY, EXZ80DOC, MBASIC etc?
Just to show I'm still chipping away at ZiCog when I have time here is version 0.6. Here I have moved the Z80 BIT, RES and SET instructions into overlays and managed to get them through the CPU exerciser tests.
Now that we have started on our own CP/M BIOS we should continue and create a BIOS for the TriBlade using 128 byte sectors and DMA. Also support for 8MB hard drives on SD card.
Also a quicker/easier way to get the SD card/RAM disk loaded is required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater,
Now I have the microSD working I have to figure how to get the code onto it. As I said, I cannot get PropTerminal to do a reliable transfer of data, so I butchered my own VB6. I will think about this overnight.
Don't rush into thinking about DMA - it is not possible because we share the I/O pins. However, the SD should be fast enough especially compared to the old floppies and old hard drives. Remember, there is no seeking time.
Also, I will have to start thinking about using compiler directives as in the homespun or bst compiler.
How's your TriBladeProp going?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
When I talk about "DMA" I of course don't mean real physical DMA but more "virtual" DMA within the disk emulation.
As it stands the disk access to SD card is a lot slower than I would like because:
1. The BIOS reads/writes single bytes at a time to the simulated disk through a simulated byte I/O port.
2. Both the simulated I/O ports and the simulated disk go through SPIN.
Now the SD card driver reads blocks into HUB memory when requested by the ZiCog disk emulation from there individual bytes are delivered to the BIOS RAM area (which will be in ext RAM) when requested by the BIOS.
My proposal is to modify the BIOS such that it uses a DMA transfer area (in ext RAM now) and that the disk emulator fetches 128 bytes at a time from the SD card block buffer in HUB.
This would speed things up nicely and make the BIOS and disk emulation simpler.
We need to to do this block transfer for hard disk emulation with the current BIOS anyway.
Presumably this plan fits with your ext RAM disk driver as well.
I would also like to simplify the hard disk part of the BIOS.
Ideally I'd like to be able to get data exchanged between SD and BIOS DMA buffer entirely in PASM.
It would be great to use homespun or bst compilers so as to maintain both HUB and external RAM versions from the same source.
My TriBlade will be progring slowly, I'm very tied up with real work at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: Real work ? you mean getting those nice features to work (SD-> BIOS block ?) Some new boards arrived today... I have to write some papers and do experiments but I can only think about those nice green boards that I'll like to populate _now_... when hobby becomes an obsession ... it is time to dump the job!
Comments
To drive it there is a new CBIOSX.COM as well.
Sorry this is sill using 137 byte sectors/blocks. Changing the BIOS to use 128 byte sectors is easy. Trouble is it then requires changes to the SIMH emulator to handle that so that I can test it.
Plan is to make a simple program that translates SIMH Altair disk images into 128 byte/sector images for use on the TriBladeProp both as RAM disks and SD card files. Then make a custom BIOS for the TriBlade to handle these. I can't test this until I get my TriBlade unless Cluso wants to have a go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think it is not nessesary to have it SIMH compatible.
Only zicog for work on it as fast revritable disk.
For Compilatrs, WordStar and simlar programs.
With end of work simply copy it to SD for storage
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I assume you'd probably need the full Z80 set done?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
With the N8VEM the only program the board starts off with is xmodem. Then you use xmodem to transfer over files, which is maybe 10-20 seconds at 38400 baud. The thing about that is that the board saving the data does all the work with sectors and file allocation. So the file could come from the SIMH or anywhere really, and as it comes down the cable it just ends up a stream of bytes and then xmodem and CP/M sort out where those bytes go, ie which track and sector.
I've got a triblade prop board now (thanks Cluso99!), so now I need to get some parts.
As an aside, I've had a N8VEM on the net for the last few days and been testing telnet and bulletin board software with people logging in from the Vintage Computer Forum. There are some issues with file transfer to sort out, but a lot is working and some people have left messages, run programs, run wordstar etc. The Zicog looks like it might be getting close to this stage too. We are using a software bridge on a PC to go from ethernet to serial, but maybe this sort of thing could reside on a prop as well?
Re: "What is the purpose of emulating a processor that's over 30 years old on the prop? " Ah - a good question.
For me, it is a matter of solving a problem. I want to get data from a to b in a remote setting. Real data too - like a jpg photo triggered by an animal walking past. Or the level in a stock trough. Wires don't work - the wildlife chews them and lightening is strangely attracted to them. Buried wires are impractical down a cliff and through rock. Lasers won't work through mist. Radio is the practical answer. You can throw heaps of power at a radio problem but there are licence issue as well as getting the power to a remote setting. Solar costs $50 per watt if you want 24 hour reliability so you need flea power. So I'm working on multiple low power radio transceivers that can automatically find each other and have enough internal intelligence to work out optimum routes for messages. I've built a system using picaxes, but there are always bugs and fixing bugs is hard when you have to hike down a cliff each time to reprogram a board. So this leads to the concept of a board that can compile its own programs on itself, plus send complete files including updates to communication programs. This means some sort of operating system is needed. Plus - you might want to run a batch file on startup, and you might want to edit that batch file, so you need a text editor. CP/M can do all these things and probably represents the simplest operating system that can. Propeller can do most of these things, but not all because it can't recompile programs on itself - you still need a PC. So combining the two gives the best of both worlds.
Oh, and I guess the other reason is because it is a totally nerdy propellerhead sort of thing to do *grin*.
Post Edited (Dr_Acula (James Moxham)) : 3/22/2009 3:11:19 AM GMT
A number of people have started receiving the TriBladeProp PCBs (UK, USA, Netherlands & Australia) so I will answer questions on the TriBladeProp thread (page 3) http://forums.parallax.com/showthread.php?p=786418
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the 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 guess we don't have to be SIMH compatible in the end. Compatibility has been very convenient to get started with. It's a kind of bootstrap "chicken and egg" problem. Having disk images and BIOSs that one can copy to the Prop and they just work saves having to debug an emulator and a BIOS and all at the same time.
Baggers:
I'd love it if someone wants to take ZiCog and incorporate it into a an Amstrad emulation, or a Sinclar, or whatever. Sure we need accurate Z80 emulation, that is nearly done. Not sure if we will have the speed. But that's just the beginning of the problems though:
1. Amstrads used bank switched memory to get to 256 or 512K RAM. We can add bank switching to ZiCog but it is another speed hit.
2. Amstrad screen could display 90 characters on a line. Can we do that from a Prop with VGA? Not to mention that the video was bit mapped in a very odd way.
3. They did use some funky hardware in some models. Like the "Roller RAM", video hardware etc.
I'd like to find the smallest VGA screen that will display 80 characters per line legibly and build a portable CP/M computer with it and Cluso's TriBlade.
Dr_A:
That 137 bytes comes from the sector size used on old Altair floppy disks, as Sapieha points out.
Kwin:
That's amazing. I would be overjoyed if you have a real world application for all this. Please let us know if you proceed with that. At some point I'm going to create a Intel 8080/85 only version of ZiCog, which will be called iCog. This will be a lot smaller and have 8080 accurate flag settings. Could be useful in recycling code from old 8085 system EPROMs if you really can't or don't want to rewrite that code.
bmb!:
I have no idea why we are doing all this[noparse]:)[/noparse] I go along with the statements of Cluso, Dr_A, Mike etc. and as George Mallory said "Because it's there"
When I started the 8080 emulator, PropAltair, over a year ago it was just as an exercise in learning what tricks one could do with this curious new Propeller chip. Since then it has grown a life of it's own. I never expected that it would attract as much interest as it has. Many people here have helped along the way, especially Cluso who has now developed a great hardware platform for it to live on. At some point I have to write all this up on it's own web pages with full credits to everyone.
I always said I was not going to extend the thing to a full up Z80 emulation. But it just keeps nagging at me.
This has all been a hobby of course, and a great learning exercise. As a result the prop may well find it's way into some new products in my new work place.
If kwin has a real use for the emulator that is icing on the cake.
After that it's back to crossword puzzles or watching TV......no no I can hear that 6809 emulator calling me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm not so sure ... If You use Copy from R: RAM dirve to A: else B: SD Drive's·SIHM formated·COPY comand .. It wil stil be SIMH compatible
Ps. Have R: drive only ´for Write intensive work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 3/22/2009 2:01:53 PM GMT
Yes, I was just tinkering with the BIOS with a mind to do something like that.
1. Add a new RAM disk drive type to the BIOS that uses 128 byte sectors and is small enough to fit in 960K RAM space.
2. Use that RAM disk type for the B: drive. This will still be on SD card on my demo board hardware.
3. Boot up the Propeller ZiCog with the new BIOS and check that it works FORMAT, DIR, PIP etc.
4. COPY the A: drive to the B: drive on SD card.
The B: drive is now our required RAM disk image.
Now how to get that off the SD card which currently is is just a concatenation of CP/M disk images so my PC cannot read it.
Hopefully under Linux I can use the dd command to pull the bytes off the SD card into a file.
Then:
5. Modify the BIOS again to use the new RAM disk type for drive A:
6. Use dd again to copy the SD's B: image to A: (Or a simple spin program)
7. Boot the propeller ZiCog again and check all is OK with the A: drive .
Now Cluso has a RAM disk bootable drive A: image and BIOS to go with it.
On the other hand I might not bother as Cluso squeezing the 137 byte sectors into 128 byte blocks in the RAM disk and faking the spare bytes when presenting them to ZiCog.
Edit: Oops I forgot, the resulting image in the above plan would be 128 byte sectors each sitting in a 512 byte SD card block so we have to remember to get ZiCog to put 4 sectors in a block for the new drive type to get a nice RAM image.
I just noticed that the BIOS we are using detects when it is running on a Z80 and then uses LDIR. Just as well LDIR was one of the first Z80 ops I tested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/22/2009 2:38:48 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I was thinking since we have more RAM, to do a Spectrum [noparse]:D[/noparse] as the spectrum would be the easier of the two to emulate as the ZX81 has to do some screen display stuff.
And yes, I have the ROM images.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Once I solve the problem of reading the code from the PC via PropTerminal (I have a bug/s!), I can manipulate the bytes/sector within spin and write to the SRAM in the pasm routine. At the moment all disk activity in the ZiCog goes via a spin cog, but I see later that being cog to cog pasm via hub command directly. I see the SRAM disk cog also handling the microSD also. So the only thing that CPM will need to know is how big a particular disk is.
I would think an 8088 emulation might be a good idea later on. That way we could run DRDOS, Turbo Pascal, etc. We have enough RAM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
The obvious ultimate goal is to load either from microSD or Flash.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Testing on the 137 byte sectors indicates that the first 3 bytes are $A7 $OE $D2 and the last 6 are $B7 $C8 $CD $A5 $2B $00.
So I will base my RAM Disk on 128 byte sectors and return the constants to make the buffer look like the 137 byte sector. This doesn't waste the space and makes the pasm code easier (no maths).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>BrainDamage!!! Is that Leor "BrainDamage" Zolman. If so I am honoured that you should turn up here on this thread.
Good ole' Google....but evidently it takes a while sometimes for board posts to make their way into the database...
>I always assumed BDS C restricted itself to 8080 instructions. Those simple tests I have done with it on the Prop emulation work just fine. But they do not use such things as memcmp or strcpy. For sure I want to get all the flags right in ZiCog so that this works as you say.
I took a look at Z80 opcodes early on and decided there was little or no advantage to using them in the generated code; too convoluted. I really couldn't improve on the basic fetching/storing and calculation operations by using Z80 ops, so what was the point... however, internally, BDS C does a lot of block moves during compilation because it's shifting stuff up and down in memory dynamically. Since the Z80 block moves do run faster than unwound 8080 loops, I took advantage of that one feature only. So the first compiler module (cc) does it (by checking the parity flag behavior) in the block move section, and I *believe* the block move library function(s) [noparse][[/noparse]I can't even recall how many there were] also make the check.
Take care,
-leor
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Those sectors look just like my hexdumps.
The CP/M looks to be running fine.
I can only guess the sectors it is reading are not quite right. I'll have to see how we can debug this a bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
PRI in_dskread 'Handle reads from the floppy disk read data port if altair_bidx == 0 'Read a new block from SD card sd_block := (altair_drive * tracks * 32) + (altair_track[noparse][[/noparse]altair_drive] * 32) + altair_sector err := \disk.readblock(sd_block, @disk_buff) io_data := disk_buff[noparse][[/noparse]altair_bidx] if dbgcnt++ < 521 'TV.str(string("HL=")) TV.hex(io_data, 2) TV.out(" ")▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 now have the ZiCog using 64KBytes of SRAM for the code and 960KBytes of SRAM Disk. It can now (finally) do a DIR command.
I have posted the code but it is a bit rough with debug code throughout. Also a pic of the screen. It uses my new TriBladeProp·Blade #2 driver routine that I published on the TriBladeProp thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
What are you going to do next with it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Just to show I'm still chipping away at ZiCog when I have time here is version 0.6. Here I have moved the Z80 BIT, RES and SET instructions into overlays and managed to get them through the CPU exerciser tests.
Now that we have started on our own CP/M BIOS we should continue and create a BIOS for the TriBlade using 128 byte sectors and DMA. Also support for 8MB hard drives on SD card.
Also a quicker/easier way to get the SD card/RAM disk loaded is required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now I have the microSD working I have to figure how to get the code onto it. As I said, I cannot get PropTerminal to do a reliable transfer of data, so I butchered my own VB6. I will think about this overnight.
Don't rush into thinking about DMA - it is not possible because we share the I/O pins. However, the SD should be fast enough especially compared to the old floppies and old hard drives. Remember, there is no seeking time.
Also, I will have to start thinking about using compiler directives as in the homespun or bst compiler.
How's your TriBladeProp going?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As it stands the disk access to SD card is a lot slower than I would like because:
1. The BIOS reads/writes single bytes at a time to the simulated disk through a simulated byte I/O port.
2. Both the simulated I/O ports and the simulated disk go through SPIN.
Now the SD card driver reads blocks into HUB memory when requested by the ZiCog disk emulation from there individual bytes are delivered to the BIOS RAM area (which will be in ext RAM) when requested by the BIOS.
My proposal is to modify the BIOS such that it uses a DMA transfer area (in ext RAM now) and that the disk emulator fetches 128 bytes at a time from the SD card block buffer in HUB.
This would speed things up nicely and make the BIOS and disk emulation simpler.
We need to to do this block transfer for hard disk emulation with the current BIOS anyway.
Presumably this plan fits with your ext RAM disk driver as well.
I would also like to simplify the hard disk part of the BIOS.
Ideally I'd like to be able to get data exchanged between SD and BIOS DMA buffer entirely in PASM.
It would be great to use homespun or bst compilers so as to maintain both HUB and external RAM versions from the same source.
My TriBlade will be progring slowly, I'm very tied up with real work at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.