FWIW, I once wrote some firmware (ROM resident I/O code) for a Z80 Datapoint computer to handle the display, keyboard, floppy disk, real time clock, and serial I/O channel. It also implemented a multitasking kernel so the operating system never saw the actual interrupts. I was impressed with the Z80's instructions and vowed to make heavy use of the fancy ones. I ended up rewriting a lot of what I had done using the index registers. The 8080 instructions were faster and took less storage in most cases.
I like to say that the Index registers are best for Database accesses.
Just imagine that you have a table of records, where all the fields are of a known length.
Then it would be easy to read of a given post using IX by loading th register with the starting point of the record, and using the offset to point to field. Then you use an ADD to skip to next record...
The problem is really finding when it's a good situation to use the 'fancy' instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
I believe the main reason the Z80 took off was its memory interface - it used far less chips, and it was compatable with the 8080, so had an immediate source of software.
The (Apple ][noparse][[/noparse] ?) and Apple /// used the Microsoft Z80 CP/M card and an external 5MB Hard Drive. Shame I threw all this out in 2000 when we moved :-( All software and hardware, direct from Apple (free) as we did designs for them (yes from Australia). The first Apple //c production (before release). Even had a Lisa (remember this - forerunner to Macintosh, but with expansion slots). Ah... I digress again !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I haven't looked in the ease or otherwise or the speed of using all those extra Z80 ops and probably never will. What I meant by "chaos" was the the way the whole thing is put together. Obviously mandated by the fact that it had to use the undocumented 8080 ops as hooks to get in to the new set which means needing one or more prefix bytes. Then there are cases where the opcode actually appears after the immediate displacement value. Ouch.
Then there are the extra rotate instructions that rotate registers and memory not just register A. Except they set flags where the originals don't so we end up with the old RLA, no flags set, and RL A, flags set. Ouch. There is similar problem with double adds and subtracts.
I get the feeling that compiler writers don't much like irregularity like that in their target architectures and it's a lot for an assembler programmer to keep in mind. So I'm not surprised most of it was ignored. Just a glimpse of this page nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html shows the scale of the problem.
What the Z80 had was speed and compatibility. A faster, simpler bus architecture and the amazing optimization of advancing the PC over the jump addresses of untaken conditional jumps rather than reading them anyway as the 8085 does !
Amazingly I never looked into all this when programming 8 bitters back in the early eighties (6809 was my favourite), now I'm glad I did not. We just moved straight from 8085 to the 16 bit world.
Ah the Apple Lisa, I saw one once. A good friend of mine bought one of the first to arrive in England when he started his consulting gig in 83. I was shocked, he paid the equivalent of my whole years salary for it!! It gave him so many hardware problems it was exchanged twice and eventually returned with a full refund.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The Lisa came with a full library of Apple software - equivalents of WordProcessor, Spreadsheet, Database, Drawing, and I forget the fifth. While it was a failure, it led to the amazing Macintosh.
68705 was my favourite. I used to throw multiple 68705's and 68701's at a job - now the Propeller does that and lots more in 1 chip. I did a soft UART and AT command set plus drive modem shipsets with one 68705U3S (3.8KB EPROM and 128bytes? RAM). I hated the 64KB limit in the 80x86 series - the 68000 was so much cleaner. The IBM PC used the Intel 8088 because they couldn't buy a piece of Motorola (at least that was the story at the time).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
In 79 a colleague of mine and computer science wiz. used to say that "IBM always held up the progress of computing by ten years".
How disappointed we were when we opened up the first ever IBM PC in the company to find it contained that ghastly Intel 8088, we were also Motorola heads. And MSDOS...bletch.
How right my colleague was.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: I used to work for a company that had several micro controllers and the MC6809 in some of its products. They were passing out all of them in favor of the HC11, a decision that should have been made.. in 1989 or so, and no in 1995!. Well, the 6809 was really neat: Two stack pointers, auto increment/post decrement and so on. I always wanted the HC11 to had the 09 core :-(, that was a nice assembler!. I read there were quite a bit of software for the 09 even that OS/9 I do not know anything about. I do not really think it would be easier than the z80, it is big endian after all..., loads/stores modify the flags, zero page addressing mode (with zero page register!).
The Z80 can run UZI80!, if someone can compile it, but it needs the full 64 kbytes though.
I loved the 6809, we built an SBC with it and created a debug monitor for it with no assembler, just assembling to HEX by hand. I forgot about the endian issue that would sure put a stick in the spokes for a prop emulator.
Clusso: I'll try not to spin out of control with these crazy ideas[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Funny you should ask, because Andrew Lynch, the creator of the N8VEM, has just branched out into a 6809 add-on.
@ heater, I've just emerged from deep within the machine code of the N8VEM, and I can report that it would take me about 5 mins of coding to rebuild the romimage to only use 8080 instructions. So if any Z80 specific opcodes are driving you crazy you can always just put an error message in for the moment.
But having fired up a pre-programmed Propeller terminal board kit (Pocketerm) for the N8VEM and have it work first time with not one bug at all, I'm even more excited about the possibility of squeezing more of the board into a Prop. A generic question - how hard would the 64k ram emulation be with the existing 8080 opcodes and the triblade prop?
Heater: The endian issue should not be a problem - you just emulate as you would normally (different code of course). Remember you are just fetching a byte at a time. When assembling a 16bit value you shift the bytes the other way.
Dr_A: The 64K ram should be a breeze with the TriBladeProp. The terminal will be in the Blade #3 and the emulator in #2. I don't think the latched addresses of the ram on Blade#3 will be fast enough for emulation, as only 2K blocks are directly accessible. Might get away with using TV instead of VGA, but it would be very tight. We can always try I suppose.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hey Heater,
If you're implementing 8080/Z80 emulation and want to run BDS C, don't forget the different behavior wrt the partity bit (I believe it was) when incrementing register A.... BDS C uses that to detect a Z80 and uses block moves to speed things up
Dr_Acula (James Moxham)
Funny you should ask all this hacking I have been doing lately drove me to dig out my old SWTP 6800-6809 machines I had a copy of Flex and OS9 kicking around somewhere the problem is though I no longer have any 5 1/4 in disk drives and the eprom boot loader code, I do have a few copies of Buffalo and have even converted my heath kit ET3400 6800 to run the 6809 but I would love to do some kind of prop motorola combo
if anyone ca read 5 1/4 disk and wants to post copies of flex or os9 for the rest of us just ask I dont think there are any copy right rules left since both OS are quite obsolete I also have the full print out of Flex source and SWTP boot source on paper ·
I have a 5.25" floppy-drive or two, but I'm not certain about their status.
Or the ancient 386 I use them in. I know I have a 'CatWeasel' ISA-card that I've meant to install in it, though...
(A CatWeasel is a floppy-controller that's 'a bit' more flexible than ordinary controllers and allows you to read a lot of different formats)
I REALLY need to get my 'office' sorted soon...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Heater, my apologies for stealing your thread for a minute.
There are a few of you I believe (and heater) are going to try the TriBladeProp and heater's ZiCog project. Here is the recommended parts for the Blade #2 section of the circuit (just for starters, other bits can be added later). I haven't included the power supply or propplug sections, nor for the Blade for Terminal emulation (which can be its own thread) or it's connections to Blade #2.
U21, U22, U23, X21, R1, R21, R22, RN1, LED2 (how about pretty blue for the emulator), C21-24 ,J21 (and wire link U25-11 to U25-17 we will need to remove this later for extras, so if you cannot desolder a these holes, wire link U21-36 to U23-22). This should be self explanatory from the circuit diagram and BOM (Bill of materials). Buy the 512Kx8 as they are cheap and I think there is a good chance we will use the extra space for a RAM Floppy. If you want to keep the board flexible you will need plenty of pin stakes and links(shunts) - I think I forgot to list shunts on the BOM. Otherwise you can solder wires instead.
Thanks heater
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This has all 8080 ops in place and tested. The T8080.COM diagnostic passes with flying colours.
Most Z80 ops are in place and most of those are not tested.
As built here it will display on PropTerminal and step through the T8080 diagnostic when a key is pressed. When you get to around PC=1EA0 it will show that 01 is output to a port indicating a PASS.
I'm having trouble doing any speed tests. When I set the thing up for full speed running the test seems to screw up. I'll try to isolate the problem and if I can't fix it I'll post it here for review[noparse]:)[/noparse]
No probs Cluso. Can't wait.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How are you doing IN and OUT? I'm thinking that on a real board, many of the IN and OUT statements do things like set up a uart or a PIO. But on a simulation, these things would be coded in other ways. (the traditional way is with a PEEK and POKE). At the very simplest level, the baud rate could be set and IN and OUT send or receive a byte from a serial port on the prop.
But thinking this through further, there is some CP/M code where there are two IN statements for the serial port - one address gets the byte, and the other just checks if a byte is there. I think you need both.
I'm thinking of the absolute simplest way 8080 or Z80 could interface with the propeller subroutines. Eg the keyboard - check if a byte is valid and get the byte. For a serial port, ditto. To output a byte to the vga terminal VT100 code. Output a byte to a serial port. Ok, that is 6 addresses. I suppose if you already have 6 then you may as well add a few more and use that as the interface to the prop eg an OUT to a particular address is trapped by the simulator code and changes the baud rate.
Dr_Acula (James Moxham) said...
Amazing!
...there is some CP/M code where there are two IN statements for the serial port - one address gets the byte, and the other just checks if a byte is there. I think you need both.
It's a pedantic point but CP/M does not use IN or OUT at all. CP/M makes use of a user written BIOS which is responsible with for interfacing with the physical hardware. In any emulation scenario you can define your own virtual machine which can be as simple as you like.
Brian, interesting point. Although CP/M was distributed from DR with a working BIOS for whatever real hardware and so that BIOS could be considered part of CP/M. On the other hand if I remember correctly the first CP/M releases came with a "BIOS" that actually used the services of Intel's Intelec development systems BIOS to do the actual IO and so did not have IN or OUT. So a bit shady here.
Dr_A, I have done the IO for PropAltair and ZiCog the only way I know how. There are three variables defined in HUB RAM, io_port, io_data and io_command. When emulating an OUT operation the CPU places the instructions port address into io_port , the data into io_data and then sets io_command to indicate a output. Then it waits in a loop for someone to deal with that and set the io_command back to zero. The "someone" is the simulator IO system which is a loop in SPIN that polls io_command. When it sees command is "out" it reads IO port and data. From the port in then knows it has data for a disk operation or console and can handle it appropriately making calls to sd card routines or serial port routines. When done the polling loop sets command back to zero and the CPU can then continue.
Input is much the same but the CPU sets io_port and io_command and then waits for the SPIN polling loop to fill in io_data and set command back to zero.
In this way we can simulate as many ports as we like. PropAltair has: conin, conout, the floppy disk command and status and the SIMH port for controlling simulation as per Aaltairz80.
Now because I am using the exact same BIOS code as the SIMH AltairZ80 it is about as simple as can be. For example there is no OUTs setting baud rates and other serial port things because there is no UART.
My intention has always been to use SIMH AltairZ80 CP/M files unchanged, no custom BIOS. Rather, get PropAltair to behave like SIMH.This saves having to maintain yet another customized CP/M BIOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm cannot wait to try your code heater... I dare not put it on my propproto or I might not resurface... I'll just have to wait till during the week for my pcbs
Your interception of the In and OUT instructions, while probably not the fastest, are certainly the way to go for compatibility with existing code. Later, when things settle it might be worth revisiting the BIOS to write native prop code for this. Thats why the mac works so well. It has a huge BIOS specifically tuned in assembler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The current IO implementation is quick and dirty but it is also very flexible. It's easy to change from PropTerminal to TV_text for example.
The big bugbear at the moment is that the SD file system is working very slowly as it exchanges one byte at a time with the BIOS via SPIN. What I would like to do eventually is to write a version of the SD card driver that instead of having a SPIN interface would interface directly to the emulators IO control block in PASM. This would be a lot quicker.
The next step would be to abandon my rule about using the SIMH AltairZ80 BIOS and create a custom BIOS that uses DMA for the floppy disks. With this and a direct link to the SD card COG it should really fly.
The AltairZ80 BIOS already uses DMA for the hard disks.
Not sure it's worth bothering with speeding up the console interface but perhaps it would be nice to have super fast serial links there and for the PUNCH device.
A huge BIOS is OK as long as most of it is in other COGs. If you see what I mean.
WARNING Do not put this in your Prop Proto Board. This thing has already distracted me from far too much real work[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oh, Cluso, I forgot. The way you describe the external RAM access on the TriBlade it sounds like this thing might even get quicker, especially if we have WORD read and write access functions.
Currently I only have 11 LONGs free but I'm sure we can fit this in one way or another.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I dont expect the ram access (provided we dont have to do a lock mechanism between cogs) to be any slower than hub access, and possibly faster. Especially if using multiple accesses like a floppy sector it go perhaps twice as fast as hub access. Of course, will have to wait and see.
There will be some trials to do for this in the following week(s) - I'll do that once the boards are running.
Once I work out the fastest access I'll let you know and you can add it into your ZiCog.
I am presuming you will need:
* normal random byte access (program and data)
* string access (which can also be used for the Floppy/Hard Disk emulation)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'm definitely interested in a 6809 emulator; I have the color computer ROMs all ready
to go (and indeed some physical color computers upstairs).
I tried this myself and was not able to get it to work. I do have a full 6809 emulator
in Perl; that was what I was using to figure out how to organize a PASM version, but
I was not able to convince myself that it would fit. Maybe I'm wrong.
The Perl emulator is kind of cool; I can actually run *huge* color computer
programs with it (and I found some bugs in some other 6809 emulators that I
compared against a real CoCo).
The 6809 does have some oddities; some instructions set some flags, and others
set different flags, and getting that 100% correct is a bit tricky. But it's not too bad.
The Perl simulator is 1176 lines long; I'm happy to share it with anyone if it
would help (although of course there are lots of 6809 emulators out there).
Cluso, For the CPU the most important external RAM interface is random BYTE read/writes as you say. Next is WORD reads/writes. Would be nice to have WORD read/write functions that go straight to the RAM rather than through the aforementioned BYTE functions. Save some call overhead and perhaps some address set up overhead.
I suppose string access could be used in the CPU for the Z80 string ops LDIR etc. but I'm not inclined to worry about it, bear in mind we are running out of COG space here. (Hmm... thinking about it COG space is not an issue here as we could replicate the RAM string access code in all the Z80 string op overlays)
String access would be useful in the COG that is doing hard disk emulation (and perhaps floppy) as it can "DMA" sectors straight from SD card to Z80 memory.
As for LOCKS around the RAM access, let's do without. We should be able to arrange that only the CPU COG or only the disk COG etc is "active" at a time.
I know the BIOS I'm using goes into a busy wait loop after ordering an HD sector while the HD controller DMA's the data accross. BUT we can arrange the IO to hang up the CPU while the DMA is being done. The BIOS would never know.
Note: It is important that after each RAM access all the RAM pins are back in their "idle" state and that no address/data etc is being driven out by a COG so that any other COG can get a go. But I'm sure you thought of that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Rokicki: I promised Cluso that I would not think about 6809 until the Z80 is done.
But I have a gut feeling that using Cluso's magical suggestion of placing multiple jump vectors in each dispatch table entry the 6809 must be doable. One has to have a good hard look at the instruction set and figure out what the fundamental operations are and then effectively code the emulation by arranging those fundamental operations for each instruction in the dispatch table.
As for the flags, don't code the flag setting into the operations themselves. There are only a handful of different ways the flags can be set so perhaps use the spare 5 bits of each dispatch table entry to select routines which sort the flags out correctly.
Have you had a look at the ZiCog code? Ignore the overlay stuff and I think the way the dispatching is done is quite readable (I hope).
What kind of hardware do we need to support for a CoCo? I understand it hand some funky memory management and graphics chips in there. Does anyone know how all that worked?
I always had a soft spot for the 6809 so I'd love to see this happen. I'd like to see FLEX or OS9 running[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Just imagine that you have a table of records, where all the fields are of a known length.
Then it would be easy to read of a given post using IX by loading th register with the starting point of the record, and using the offset to point to field. Then you use an ADD to skip to next record...
The problem is really finding when it's a good situation to use the 'fancy' instructions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
The (Apple ][noparse][[/noparse] ?) and Apple /// used the Microsoft Z80 CP/M card and an external 5MB Hard Drive. Shame I threw all this out in 2000 when we moved :-( All software and hardware, direct from Apple (free) as we did designs for them (yes from Australia). The first Apple //c production (before release). Even had a Lisa (remember this - forerunner to Macintosh, but with expansion slots). Ah... I digress again !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
Then there are the extra rotate instructions that rotate registers and memory not just register A. Except they set flags where the originals don't so we end up with the old RLA, no flags set, and RL A, flags set. Ouch. There is similar problem with double adds and subtracts.
I get the feeling that compiler writers don't much like irregularity like that in their target architectures and it's a lot for an assembler programmer to keep in mind. So I'm not surprised most of it was ignored. Just a glimpse of this page nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html shows the scale of the problem.
What the Z80 had was speed and compatibility. A faster, simpler bus architecture and the amazing optimization of advancing the PC over the jump addresses of untaken conditional jumps rather than reading them anyway as the 8085 does !
Amazingly I never looked into all this when programming 8 bitters back in the early eighties (6809 was my favourite), now I'm glad I did not. We just moved straight from 8085 to the 16 bit world.
Ah the Apple Lisa, I saw one once. A good friend of mine bought one of the first to arrive in England when he started his consulting gig in 83. I was shocked, he paid the equivalent of my whole years salary for it!! It gave him so many hardware problems it was exchanged twice and eventually returned with a full refund.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
68705 was my favourite. I used to throw multiple 68705's and 68701's at a job - now the Propeller does that and lots more in 1 chip. I did a soft UART and AT command set plus drive modem shipsets with one 68705U3S (3.8KB EPROM and 128bytes? RAM). I hated the 64KB limit in the 80x86 series - the 68000 was so much cleaner. The IBM PC used the Intel 8088 because they couldn't buy a piece of Motorola (at least that was the story at the time).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
How disappointed we were when we opened up the first ever IBM PC in the company to find it contained that ghastly Intel 8088, we were also Motorola heads. And MSDOS...bletch.
How right my colleague was.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There's tones of software out there for it, but only if we can get source code for an OS and BIOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The Z80 can run UZI80!, if someone can compile it, but it needs the full 64 kbytes though.
Ale... nearly there... have the bits... waiting for the pcb
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
MP/M is on my loooooong term plans for the Prop.
I loved the 6809, we built an SBC with it and created a debug monitor for it with no assembler, just assembling to HEX by hand. I forgot about the endian issue that would sure put a stick in the spokes for a prop emulator.
Clusso: I'll try not to spin out of control with these crazy ideas[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Funny you should ask, because Andrew Lynch, the creator of the N8VEM, has just branched out into a 6809 add-on.
@ heater, I've just emerged from deep within the machine code of the N8VEM, and I can report that it would take me about 5 mins of coding to rebuild the romimage to only use 8080 instructions. So if any Z80 specific opcodes are driving you crazy you can always just put an error message in for the moment.
But having fired up a pre-programmed Propeller terminal board kit (Pocketerm) for the N8VEM and have it work first time with not one bug at all, I'm even more excited about the possibility of squeezing more of the board into a Prop. A generic question - how hard would the 64k ram emulation be with the existing 8080 opcodes and the triblade prop?
Dr_A: The 64K ram should be a breeze with the TriBladeProp. The terminal will be in the Blade #3 and the emulator in #2. I don't think the latched addresses of the ram on Blade#3 will be fast enough for emulation, as only 2K blocks are directly accessible. Might get away with using TV instead of VGA, but it would be very tight. We can always try I suppose.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
Some inspiration for you:
http://en.wikipedia.org/wiki/TRS-80_Color_Computer
http://www.discover-net.net/~dmkeil/coco/coco3.htm
http://coco3.com/
http://www.axess.com/twilight/sock/
I never had a Coco, but I used to dream of owning one, as being better than my Apple ][noparse][[/noparse] clone & Atari 400 & Atari 800...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
If you're implementing 8080/Z80 emulation and want to run BDS C, don't forget the different behavior wrt the partity bit (I believe it was) when incrementing register A.... BDS C uses that to detect a Z80 and uses block moves to speed things up
Funny you should ask all this hacking I have been doing lately drove me to dig out my old SWTP 6800-6809 machines I had a copy of Flex and OS9 kicking around somewhere the problem is though I no longer have any 5 1/4 in disk drives and the eprom boot loader code, I do have a few copies of Buffalo and have even converted my heath kit ET3400 6800 to run the 6809 but I would love to do some kind of prop motorola combo
if anyone ca read 5 1/4 disk and wants to post copies of flex or os9 for the rest of us just ask I dont think there are any copy right rules left since both OS are quite obsolete I also have the full print out of Flex source and SWTP boot source on paper
·
Or the ancient 386 I use them in. I know I have a 'CatWeasel' ISA-card that I've meant to install in it, though...
(A CatWeasel is a floppy-controller that's 'a bit' more flexible than ordinary controllers and allows you to read a lot of different formats)
I REALLY need to get my 'office' sorted soon...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
There are a few of you I believe (and heater) are going to try the TriBladeProp and heater's ZiCog project. Here is the recommended parts for the Blade #2 section of the circuit (just for starters, other bits can be added later). I haven't included the power supply or propplug sections, nor for the Blade for Terminal emulation (which can be its own thread) or it's connections to Blade #2.
U21, U22, U23, X21, R1, R21, R22, RN1, LED2 (how about pretty blue for the emulator), C21-24 ,J21 (and wire link U25-11 to U25-17 we will need to remove this later for extras, so if you cannot desolder a these holes, wire link U21-36 to U23-22). This should be self explanatory from the circuit diagram and BOM (Bill of materials). Buy the 512Kx8 as they are cheap and I think there is a good chance we will use the extra space for a RAM Floppy. If you want to keep the board flexible you will need plenty of pin stakes and links(shunts) - I think I forgot to list shunts on the BOM. Otherwise you can solder wires instead.
Thanks heater
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
Post Edited (Cluso99) : 3/8/2009 4:59:30 AM GMT
This has all 8080 ops in place and tested. The T8080.COM diagnostic passes with flying colours.
Most Z80 ops are in place and most of those are not tested.
As built here it will display on PropTerminal and step through the T8080 diagnostic when a key is pressed. When you get to around PC=1EA0 it will show that 01 is output to a port indicating a PASS.
I'm having trouble doing any speed tests. When I set the thing up for full speed running the test seems to screw up. I'll try to isolate the problem and if I can't fix it I'll post it here for review[noparse]:)[/noparse]
No probs Cluso. Can't wait.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How are you doing IN and OUT? I'm thinking that on a real board, many of the IN and OUT statements do things like set up a uart or a PIO. But on a simulation, these things would be coded in other ways. (the traditional way is with a PEEK and POKE). At the very simplest level, the baud rate could be set and IN and OUT send or receive a byte from a serial port on the prop.
But thinking this through further, there is some CP/M code where there are two IN statements for the serial port - one address gets the byte, and the other just checks if a byte is there. I think you need both.
I'm thinking of the absolute simplest way 8080 or Z80 could interface with the propeller subroutines. Eg the keyboard - check if a byte is valid and get the byte. For a serial port, ditto. To output a byte to the vga terminal VT100 code. Output a byte to a serial port. Ok, that is 6 addresses. I suppose if you already have 6 then you may as well add a few more and use that as the interface to the prop eg an OUT to a particular address is trapped by the simulator code and changes the baud rate.
Dr_A, I have done the IO for PropAltair and ZiCog the only way I know how. There are three variables defined in HUB RAM, io_port, io_data and io_command. When emulating an OUT operation the CPU places the instructions port address into io_port , the data into io_data and then sets io_command to indicate a output. Then it waits in a loop for someone to deal with that and set the io_command back to zero. The "someone" is the simulator IO system which is a loop in SPIN that polls io_command. When it sees command is "out" it reads IO port and data. From the port in then knows it has data for a disk operation or console and can handle it appropriately making calls to sd card routines or serial port routines. When done the polling loop sets command back to zero and the CPU can then continue.
Input is much the same but the CPU sets io_port and io_command and then waits for the SPIN polling loop to fill in io_data and set command back to zero.
In this way we can simulate as many ports as we like. PropAltair has: conin, conout, the floppy disk command and status and the SIMH port for controlling simulation as per Aaltairz80.
Now because I am using the exact same BIOS code as the SIMH AltairZ80 it is about as simple as can be. For example there is no OUTs setting baud rates and other serial port things because there is no UART.
My intention has always been to use SIMH AltairZ80 CP/M files unchanged, no custom BIOS. Rather, get PropAltair to behave like SIMH.This saves having to maintain yet another customized CP/M BIOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I managed to track down the issue with running T8080.COM repeatedly as a benchmark with the following results:
1 COG ProAltair 392 KIPS
4 COG i8080_emu 406 KIPS
1 COG ZiCog 412 449 KIPS
Now we could move all the Z80's registers to COG for a further improvement.......
Na, let's get PropAltair a Z80 upgrade and CP/M back up and running first.
Just amended ZiCog result following a "proper" fix for the issue mentioned above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 3/7/2009 1:52:59 PM GMT
Your interception of the In and OUT instructions, while probably not the fastest, are certainly the way to go for compatibility with existing code. Later, when things settle it might be worth revisiting the BIOS to write native prop code for this. Thats why the mac works so well. It has a huge BIOS specifically tuned in assembler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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 big bugbear at the moment is that the SD file system is working very slowly as it exchanges one byte at a time with the BIOS via SPIN. What I would like to do eventually is to write a version of the SD card driver that instead of having a SPIN interface would interface directly to the emulators IO control block in PASM. This would be a lot quicker.
The next step would be to abandon my rule about using the SIMH AltairZ80 BIOS and create a custom BIOS that uses DMA for the floppy disks. With this and a direct link to the SD card COG it should really fly.
The AltairZ80 BIOS already uses DMA for the hard disks.
Not sure it's worth bothering with speeding up the console interface but perhaps it would be nice to have super fast serial links there and for the PUNCH device.
A huge BIOS is OK as long as most of it is in other COGs. If you see what I mean.
WARNING Do not put this in your Prop Proto Board. This thing has already distracted me from far too much real work[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Currently I only have 11 LONGs free but I'm sure we can fit this in one way or another.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There will be some trials to do for this in the following week(s) - I'll do that once the boards are running.
Once I work out the fastest access I'll let you know and you can add it into your ZiCog.
I am presuming you will need:
* normal random byte access (program and data)
* string access (which can also be used for the Floppy/Hard Disk emulation)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps:· SixBladeProp, TriBladeProp
· 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
to go (and indeed some physical color computers upstairs).
I tried this myself and was not able to get it to work. I do have a full 6809 emulator
in Perl; that was what I was using to figure out how to organize a PASM version, but
I was not able to convince myself that it would fit. Maybe I'm wrong.
The Perl emulator is kind of cool; I can actually run *huge* color computer
programs with it (and I found some bugs in some other 6809 emulators that I
compared against a real CoCo).
The 6809 does have some oddities; some instructions set some flags, and others
set different flags, and getting that 100% correct is a bit tricky. But it's not too bad.
The Perl simulator is 1176 lines long; I'm happy to share it with anyone if it
would help (although of course there are lots of 6809 emulators out there).
I suppose string access could be used in the CPU for the Z80 string ops LDIR etc. but I'm not inclined to worry about it, bear in mind we are running out of COG space here. (Hmm... thinking about it COG space is not an issue here as we could replicate the RAM string access code in all the Z80 string op overlays)
String access would be useful in the COG that is doing hard disk emulation (and perhaps floppy) as it can "DMA" sectors straight from SD card to Z80 memory.
As for LOCKS around the RAM access, let's do without. We should be able to arrange that only the CPU COG or only the disk COG etc is "active" at a time.
I know the BIOS I'm using goes into a busy wait loop after ordering an HD sector while the HD controller DMA's the data accross. BUT we can arrange the IO to hang up the CPU while the DMA is being done. The BIOS would never know.
Note: It is important that after each RAM access all the RAM pins are back in their "idle" state and that no address/data etc is being driven out by a COG so that any other COG can get a go. But I'm sure you thought of that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But I have a gut feeling that using Cluso's magical suggestion of placing multiple jump vectors in each dispatch table entry the 6809 must be doable. One has to have a good hard look at the instruction set and figure out what the fundamental operations are and then effectively code the emulation by arranging those fundamental operations for each instruction in the dispatch table.
As for the flags, don't code the flag setting into the operations themselves. There are only a handful of different ways the flags can be set so perhaps use the spare 5 bits of each dispatch table entry to select routines which sort the flags out correctly.
Have you had a look at the ZiCog code? Ignore the overlay stuff and I think the way the dispatching is done is quite readable (I hope).
What kind of hardware do we need to support for a CoCo? I understand it hand some funky memory management and graphics chips in there. Does anyone know how all that worked?
I always had a soft spot for the 6809 so I'd love to see this happen. I'd like to see FLEX or OS9 running[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.