Anyone actually started working on VT100 for the Prop yet? Can't be that hard to implement
Perhaps it's time to give PropCOMM a serious overhaul and plug AiGeneric into it for 40x24 (or higher) terminal use.
I've been studying the code more and all the posts. I wish I'd found this thread back in March...!
There are lots of ways to compile that don't involve Microsoft's M80. Indeed, the M80 is probably the slowest option.
The N8VEM group has gone for TASM and various recent packages of files include TASM as well. To create a new eprom image, a number of files need to be compiled together, including CP/M. The easist way to do this is with a batch file, and the whole compilation process takes about 1/2 a second. Then about 10 seconds to program an eprom with a Willem programmer. Then put the eprom in a ZIF socket. All a bit old-school really and the propeller could certainly introduce some efficiencies there.
listing of build-n-38.bat (38 denotes a 38k baud serial version)
The cunning bit is the second to last line with copy /b
This combines each of the .bin files created by tasm into one big file. All you need to do is make sure each .asm program has an org entry at the end to make the length a known quantity eg the format program has
.org $04ff ; fill up space so RTC and xmodem in the right spot
.db $00
.end
All the above code is in Z80 but in TASM can do 8080 and a whole bunch of other opcodes. (A great thing about a Table Assembler). A number of the original n8VEM files were 8080 opcodes but I prefer Z80. You can change them back if you like.
If you are building lots of cp/m images for a propeller, you would probably edit them in a text editor on a PC. Then compile with a double click on the batch file. Then get the binary onto the propeller somehow (maybe via an SD card reader/writer). Maybe via custom software in .net through to the propeller. All your simulator needs is the location of that binary and it can start emulating the codes.
I've tried compiling new CP/M images on the board itself but it is slower. M80 is useful for tiny little self contained programs but not for the operating system itself.
So you are free from Microsoft!
Having looked at the code in detail, I am wondering about your twin propeller approach.
CP/M *really* needs 64k of ram. Consider MBASIC. If you load it up then CP/M takes some space, and MBASIC takes some space and then you only have 30k left for the program. Ditto Wordstar - you need some space to put your text!
If I am reading the propeller datasheets right, I think that there is only 32k of ram?
So a solution could be to add a single ram chip. And this is something I've agonised about for years, but I think a single 128k chip (and don't use half the chip) works out better than two 32k chips. A 128k ram chip from futurlec in a DIP package is only $2.90
Hmm - twin propellers or some other solution. I'm brainstorming the various options. I'm going towards one propeller with a ram chip and that emulates the cpu. And another propeller which is the "terminal" propeller - that does the vga screen and keyboard. And an sd card for all the storage, though I'm not sure which propeller that fits in with.
heater said...
I'll probably sign up for the N8VEM when I have a free moment or ten may even get a board.
However I think I have a different take on all this. I will one day build my original plan of using am 8080 together with some RAM with one or more Propellers as the ONLY peripheral devices responding as IO ports. Thus no need for old original style parallel or serial port chips etc.
Alternatively a multi Prop board and use the emulator as I said before.
I have no interest it getting real floppy or hard drives connected, better to just use and SD card or FLASH chips.
On of my guiding principles is to be able to use the CP/M sources from the SIMH project unchanged, so as not to have to maintain a separate CP/M version. So it is necessary for the Prop to implement SIMH's idea of floppy/hard disk and serial ports etc.
The VT100 terminal emulation on a Prop is a major part of this, sadly I have no solution for it yet. I suspect someone here as done this already though.
Hi!· Send me a PM and I'll send you a personal invite to the N8VEM home brew computer group.· The PCBs are all available for builders to get their own parts and make their own home brew Z80 CP/M computers.· So far there is the SBC, ECB backplane, ECB bus monitor (sort of like a Jade Bus Probe for the ECB if you remember those), and an ECB prototyping board. ·The Propeller is a natural compliment to the N8VEM system and I am building a Terminal Replacement Board for it using an ECB prototyping board and a home brew Propeller prototype board.· Today I got the first connection to work so it's coming along nicely.
Adding the VT100 compatibility should be quite doable once the hardware is in place. Right now the TRB design is just a TTY interface and adding escape sequence processing, at least for a good portion of the VT100 commands, should be not a problem.
The N8VEM design is quite flexible so you can use SD or CF if you want.· I am building a Disk IO board with IDE and a NEC765A style FDC on it.·· Not everyone wants old style floppy drives but some of the vintage/retrocomputing hobbyists are really "champing at the bit" for a new FDC to recover their legacy data.
One of the really great features of the Propeller is the support for standard serial interfaces.·· That tremendously simplifies the connection with vintage/recomputing/home brew computers since UARTs are standard items in Z80 CP/M environment.
Hmm.. TASM is nice but what I was looking for is a way to rebuild CP/M within CP/M with no need for a PC. May be slow but I like the idea of my CP/M being self sufficient. And preferably using original Digital Research tools just to be authentic.
To be a full up CP/M system my 8080 emulator only needs some RAM and a VT100 compatible terminal. The RAM part I was holding off because it was nice to run it on a standard Prop demo board and, well, I'm holding out for the Prop II with lots more RAM.
The VT100 I have not really looked into yet.
Full Z80 emulation seems a bit too much for the Prop. Fortunately CP/M does not need it but some programs do. Is it so that a couple of Z80 instructions is all we need ? If so it might make sense to add those to the emulator.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If I recall correctly (and my CPM use was quite a few years back) there were several terminal emulation programs available for CPM, and most of them included VT100 emulation. Perhaps one of these programs is still available. The name "Softerm" or something like that is all I can recall.
As for full Z80 emulation I have a question and a possible suggestion. How many cogs does the emulator require? If the answer is only one or two then we could use another one or more cogs for the instructions that are unique to the Z80.
How about ASM.COM? Z80 and 8080 codes. ASM came standard with CP/M and is on the SIMH site. Then use LOAD. That avoids all microsoft products [noparse]:)[/noparse]
Even though you might write something in Z80 opcodes, I don't think unique Z80 opcodes are needed. Looking at some typical code there are only about 20 instructions that are used regularly. All the code I'm using is just 8080 code. Unique Z80 codes like EXX and LDIR don't seem to occur in CP/M or output from other compilers eg basic. Maybe later in the history of CP/M people started adding Z80 opcodes but I suspect there was pressure not to so as to maintain backwards compatability.
Re a Terminal - I've probably added some confusion by not defining this. Many programs will run on a PC and emulate a VT100 terminal. Eg Hyperterminal and Teraterm.
What the N8VEM group is working on is a propeller board that is completely independent of a PC. It has three connectors - a keyboard connecter, vga connecter and an RS232 connector. Another board sends characters and the propeller displays them. But it is very useful to be able to move a cursor around on a screen - that was how wordstar worked and how many games worked. VT100 had a rather large sequence of commands (to change colours, bold, flashing etc), but there is a simpler subset that would just be moving the cursor and maybe bold text. Even colour changes are not that important.
Some people call this a Dumb Terminal. Some call it a Teletype terminal. They were green or orange or white usually - some were colour but that was just before CGA etc came along. Then in the 90s you could get a dumb terminal in a rubbish skip for free. And now they just don't seem to exist any more.
I'm still intrigued by emulating an 8080 on a propeller - it radically reduces the chip count.
Addit - while I was writing this, lynchaj has jolly well just gone and built a terminal and posted a picture of a propeller terminal that is working!
Post Edited (Dr_Acula (James Moxham)) : 12/24/2008 8:25:31 AM GMT
Am I reading it right - the thread ended because some sort of private deal was worked out?
I'm thinking a vt100 terminal would be an excellent demonstration of the propeller (as would another prop running CP/M!)
So many things could use a vt100. Basic Stamp. Picaxe. Z80 boards. So many projects use LCD displays, but go much above 20x4 and a propeller plus freebie vga monitor would end up cheaper.
I'm almost wondering about paying someone to do it and then the deal would be that the code would be donated back to the propeller community as open source. I'm not sure what someone would want for that sort of coding. I'm not sure even whether to suggest a number - because someone who is a beginner might look at it and see it as daunting but someone with experience might find it easy.
I wonder if full VT100 emulation is required. Most of the software I worked with only used basic functions (clear screen, cursor addressing, text highlighting, etc) in order to be compatible with lesser equipment. This was true of most CPM software as well.
If the basic emulation software is written using a lookup table additional commands could be added as needed.
I wonder if it is possible to fit everything in one prop with an external 64K ram chip for CPM similar to the Prop6502 project.
Does anyone have any idea if it's possible to use a Rabbit board to run CP/M? It's supposed to be Z80 compatible, but I can't find anything on Rabbit's site that says more than that programmers who like the z80 will love the Rabbit processor.
It really depends on what flavor of CP/M and how it is implemented. Although the Rabbit is Z80 like (which is still one of my favorite processors BTW) there are several differences in the instruction set which could cause a problem with I/O since several instructions were dropped. A good reference I found about the instruction differences is posted on their site at:
Mike Green said...
Thanks for the link. That answers my questions. I would need a strictly 8080 based version of CP/M
Mike
Hi Mike!· After viewing the above website, I believe the Rabbit does not support several Z80 instructions.· That wouldn't be so bad for CP/M as few applications are truly Z80 dependent (Borland Turbo Pascal for CP/M being the primary exception plus several custom applications).
However the real "gotcha" which I think you've noticed is some of those unsupported Z80 instructions are also 8080 instructions (IN, OUT) which is a major problem.· Practically all of the CBIOSs I've seen are packed with those instructions.· Also several applications which require patching will not be easily portable.
The idea behind the N8VEM SBC is a standalone unit that runs CP/M from the original sources or very nearly so.· The default software package has a custom CBIOS for its own IO but even that is pretty common stuff. The rest is straight from the Unofficial CP/M webpage DRI sources with little or no modification.· XMODEM5 did need little patch for serial IO but that was about it.· The design is intended to be low cost and use scrap electronic components to keep builder costs to a minimum.
Most true CP/M applications run straight away with no modifications on the N8VEM.· The usual restrictions apply though... any application which accessed unique hardware (formatting utilities, some terminal emulation, etc) will require patching but since the IO is so basic (8250 UART, 8255 PPI) this is pretty simple stuff.
Yes, I personally use TASM and send the binaries over to the SBC using XMODEM but that is just personal style issues.· If you want to use ASM.COM from the formal CP/M distribution it should work.· As before, you'll need patience as a 4 or 8·MHz Z80 will take much longer to assemble the CP/M sources than even an obsolete laptop.· Different builders use different tools.· I believe James prefers MBASIC.· I like straight 8080 assembler myself.
I wrote many years ago a Z80 emulator for a MIPS machine. I used the registers(32) of MIPS CPU to store the Z80 registers so it was very fast.
I was able to speed up a Gameboy emulator by a factor of two just by changing the Z80 emulator.
A similar approach could be used with a Propeller as it does have enough registers.
heater - I know you don't like microsoft products, but I've just been coding some assembly and it only takes about two seconds to compile the program below on the N8VEM board at 3.68Mhz. So a simulation on a propeller would be fine too as that isn't that much slower. If CP/M can run on a simulation then it ought to be able to do this. Start with small simple programs before moving up to a complete recompile of CP/M.
Run M80 then L80, and I wrote a simple submit file so you can do all that in one line without having to remember the switches. The switches are mainly there to generate lots of intermediate files which are useful if there is an error. M80 and L80 are out there in the CP/M world.
Z80 mnemonics but they are really 8080 codes.
This little program changes the baud rate. It has a .MAC extension.
; file 38400.mac
; sets baud rate to 38400
; changing from tasm mnemonics - replace all $nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines in a text file
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
; UART 16C450 SERIAL IS ATTACHED TO THE SECOND IO BASE ADDRESS
UART0 EQU IO_Y1+0 ; DATA IN/OUT
UART1 EQU IO_Y1+1 ; CHECK RX
UART2 EQU IO_Y1+2 ; INTERRUPTS
UART3 EQU IO_Y1+3 ; LINE CONTROL
UART4 EQU IO_Y1+4 ; MODEM CONTROL
UART5 EQU IO_Y1+5 ; LINE STATUS
UART6 EQU IO_Y1+6 ; MODEM STATUS
UART7 EQU IO_Y1+7 ; SCRATCH REG.
UART9600: LD A,80H
OUT (UART3),A ; SET DLAB FLAG
LD A,3 ; = 1,843,200 / ( 16 x 9600 )
OUT (UART0),A ; Set BAUD rate to 38400
LD A,00H
OUT (UART1),A ;
LD A,03H
OUT (UART3),A ; Set 8 bit data, 1 stopbit
ret ; back to CP/M
end
[noparse][[/noparse]screen dump - type the first line and the submit program does the rest. One line compiling!]
A>supersub zasm 38400
SuperSUB V1.1
CP/M V2.2C
A>M80 =38400 /Z/C/L/M
No Fatal error(s)
CP/M V2.2C
A>L80 38400,38400/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
guys, really, we should give this thread back to heater's project..
@heater,
A thought.. What if we take two Props (Like I did with my double stack) and
tie them together running your CP/M simulation on one, and my VT100 terminal
on the other? [noparse]:)[/noparse]
I'm putting some connecting lines between my two boards so I can work on
this. Any chance you'll get to an emulation level soon?
I am amazed at the effort and ingenuity that has gone into this project but I can't help wondering if it is worth the effort. Even here in Canada I can pick up a Z80, 64K ram, and 2 74244 IC's for about $10-15 to build a circuit similar to Dennis Ferron's Prop6502. Now the prop can be used for all the I/O (keyboard, video, disk drives, sound, serial, etc.) and we have a full speed Z80 cpu to boot.
kwinn said...
I am amazed at the effort and ingenuity that has gone into this project but I can't help wondering if it is worth the effort. Even here in Canada I can pick up a Z80, 64K ram, and 2 74244 IC's for about $10-15 to build a circuit similar to Dennis Ferron's Prop6502. Now the prop can be used for all the I/O (keyboard, video, disk drives, sound, serial, etc.) and we have a full speed Z80 cpu to boot.
Hi!· Its not the price nor the availability of the ICs which makes home brew computers difficult; its the construction technique.· You can use regular prototyping boards and point to point soldering or wire-wrap and rig up temporary SBCs.· Depending on how you do it, the results may be satisfactory but I think you'll soon see the benefits of a integrated solution and/or manufactured PCBs.· It is hard to maintain or modify prototype boards in the long term.· Not impossible just difficult.
I believe heaters approach of emulating the 8085 in software on the Propeller solves this problem by using the Propeller prototype boards and demo board.· Most of the construction is already done and only limited additions for other devices.· Its a very clean and a reliable long term solution.· However, if you see the original posting, heater points out correctly that the Propeller has 32K RAM and even with the Cog memory you'll be bumping up against the limits of a usable system to run even a stripped down 8085 monitor like the 85SDK debugmon.
For CP/M and general applications though I think it will probably require some sort of additional memory.· Maybe that could be additional serial SRAM or even a parallel SRAM.· CP/M needs at least 48K to be practical although it will run in a minimum of 16K but there is almost no useable TPA.· The overhead of the 8085 CPU emulation·requires some memory so the overall memory requirements could be significant.
Personally, as kwinn suggests I think the combination Z80 with a Propeller for programmable IO is the way to go.· The Z80 handles traditional CPU and parallel memories and peripherals with the Propeller handling all the modern IO like AT keyboard, video, I2C, and the like.· There is a lot of synergy between·a GPCPU and the uC which make a nice compliment.· That's not the first time a general purpose CPU and a uC have married up though.· Practically all the modern computers have numerous uC's and even the original IBM PC had multiple uC's on board such as 8048s, 8042s, and the like.
I'd just like to make the Propeller 8080 emulator status at this time clear:
1. All 8080 instructions are implemented.
2. The actual 8080 emulation is run by a single COG as PASM code.
3. As I ran out of COG space a handful of instructions are implemented as Large Memory Model (LMM) code.
(For those new to this LMM puts PASM instructions into HUB RAM, they are read into COG and executed there one by one, this is somewhat slower but useful for lesser used 8080 op code emulation e.g. DAA.)
4. CP/M runs just fine, DIR, PIP and all and is built from unmodified sources obtained from the SIMH emulator project.
5. Up to 8 floppy drives are emulated on an SD card by some simple SPIN code and the low level SD card drivers from the Propeler FAT file system. The actual DOS FAT layer is not used, after all we have CP/M here.
6. RAM for CP/M is limited to 24Kb within the Prop
7. Console I/O are through serial emulation and I currently use PropTerminal.
8. All this runs on a Prop demo board with SD card added.
9. All CP/M software that I can through at it has worked provided it works within the RAM limitation.
10. Speed is about equivalent to an original 8080.
11. Everything required to run is included in the down loadable ZIP for convienience.
12. Interrupts are not supported, as per SIMH.
13. Code I have writen using the BDS C compiler for CP/M works.
So at this stage it is the equivalent of 24K Altair with floppies but no hard drive.
And what's in the future future? Well more and more that seems to depend on things being done by other CP/M, 8080, Z80 enthusiasts who have turned up here recently and whose efforts I'm looking forward to checking out. But a few things are clear:
1. RAM must be increased to at least 64K. Problem is any kind of external RAM will slow things down. One option is to dedicate a whole Prop to the actual 8080 emulation using as much HUB RAM as possible and external RAM for the higher addresses as a compromise.
2. Hard disk emulation. Up to four 8Mb drives in SD card. This should be very simple.
3. Proper VT100 terminal. I'd like to see a Prop VT100 screen and keyboard emulation as a separate project. I'm sure many would find it useful.
4. Eventually I want to build an Altair lookalike front panel with all the LEDS and switches
With the above we finally arrive at a stand alone CP/M machine that can rebuild it's own operating system.
Up until now I have not ventured into custom hardware solutions for any of the above as it was unlikely that anyone but me would want to build such a thing. So I kept within the confines of a normal Prop demo board. Recently others have come up with things that would help and which people may actually have one day: Leon is working on a Prop CPLD board with some RAM. drohne235 has the Hive multi Propeller design. Then there are the ideas from N8VEM which I have yet to catch up on.
I've only just now caught up with all the posts here over Christmas so are here a few replies to points raised:
kwinn said...
As for full Z80 emulation I have a question and a possible suggestion. How many cogs does the emulator require? If the answer is only one or two then we could use another one or more cogs for the instructions that are unique to the Z80.
As I said above the actual 8080 emulation only uses 1 COG. I have pondered the idea of using multiple COGS for full Z80 emulation but I can't really see how to do it without clobbering the speed whilst handing control and data from COG to COG through the HUB. Perhaps I just haven't worked it out properly yet. Seems adding extra code for LMM execution in a single COG would be just as fast and a lot simpler at the cost of some HUB RAM but we need external RAM anyway.
Also I'm not really into full Z80 emulation. Not much software uses it and it's a lot more work.
Dr_Acula:
Thanks for all you input here re: building CP/M the N8VEM project etc. Its great you alerted me to all the other CP/M activity going on.
Inaki said...
A similar approach could be used with a Propeller as it does have enough registers.
That just what PropAltair does. And they are located at COG address zero for rapid indexing, a trick suggested by hippy.
Oldbitcollector:
Actually I've been enjoying this slight thread hijacking. It's great to see I'm not the only one keeping CP/M alive and there's been some great info coming.
The two prop idea is great. Especially if the terminal can be a useful device by itself for other projects. PropAltair has been at "emulation level" for a long time as described above. It's just been waiting for your VT100 terminal [noparse]:)[/noparse] Do you really have that? Can I have a copy ?
kwinn said...
can't help wondering if it is worth the effort.
Ha! You spotted the insanity in all this. But I'll try to defend the sanity of PropAltair thus:
1. I was already planning a proper CP/M computer using a 8085 and other old time parts I have hanging around when I was diverted by the new shiny Propeller.
2. Using a Prop for the video is a gift from God (Well Chip) in such a venture.
3. I got bored with soldering so soaking up the peripherals into a Prop was the only way to go.
4. Had to learn PASM and the 8080 emulation was my first PASM program as an exercise.
5. Lo and behold, I don't need to bother with the 8085 after all.
6. I wanted to be first to announce the possibility of running code compiled from C on the Prop. Via the BDS C compiler. Not sure but I think I was. If not then I can now be first to introduce Fortran, Pascal, PL/M etc for the Propeller [noparse]:)[/noparse]
Thanks for all your input everyone. (Don't you people have anything better to do over Christmas?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater!· Your project is great stuff and I am glad to see you succeed!· Best of luck in your efforts!· I am also very glad to see other CP/M enthusiasts working on home brew computing projects!
If there is anything you can use from the N8VEM project to help·please do not hesitate to ask!
Thank you very much for all your hard effort!· I much appreciate it!
The two prop idea is great. Especially if the terminal can be a useful device by itself for other projects. PropAltair has been at "emulation level" for a long time as described above. It's just been waiting for your VT100 terminal [noparse]:)[/noparse] Do you really have that? Can I have a copy ?
It's as close as the next thread.. Grab the _VGA version from the propCOMM2 thread.
It's been getting the most attention. Should now support most of the commands you'll need
for cursor control, etc.
I switched over the VGA because I needed 80x25. Now that I have
two different monitors on my desk, I can't figure out how I lived
without a debug screen. [noparse]:)[/noparse]
I'll try to update the TV version of the VT100 emulation this afternoon.
Re "Don't you people have anything better to do over Christmas?"
A: Nup!
Choices: Eat too much. Drink too much. Or cut code...
Last night I wrote some VB.NET code to automatically download all the useful software to a N8VEM with one keypress. Eg all the files for wordstar, plus mbasic interpreter and compiler etc.
I can now build a N8VEM from scratch in under 45 minutes:
35 minutes for soldering.
3 minutes to program the eprom
3 minutes to download all the software (38400 baud RS232)
BUT - I'll bet it could be even quicker for heater's project, because there are a lot less chips to solder (16 vs 1).
One of the essentials for any computer is a decent text editor. CP/M has many, but they all seem to need more than 24k of memory. The pukka ones like wordstar really need 64k.
This sounds like it could be a bit of a stumbling block. Is there a version 2 of the propeller in the pipeline with more memory?
Or - do you use good old SRAMs (2 32k ones or a single 128k one)? Do you drive the address and data lines directly or do you use serial to parallel like the HC595? Or do you use serial ram chips (not sure how they compare in price)? Or even old drams (which did have less pins?)
Can this emulation spare 26 lines to drive a sram directly?
I'm wondering about 26 lines to an sram, and just two lines for serial. That is 28 lines.
Then use oldbitcollector's rapidly evolving terminal to do the terminal, keyboard, and indeed, use that board to do extra serial eg to a 'printer' serial port via custom vt100 codes. And do sound on the terminal via custom vt100 as well. Even have some of the storage on the terminal?
Just some more musings - I'm not sure of the optimum answer.
As for no VGA in the house, I've got friendly with my local computer store and they are almost giveaways. Not quite completely free, but along the lines of "if you buy this $40 game you can have a couple of CRT monitors for free"
Post Edited (Dr_Acula (James Moxham)) : 12/29/2008 12:53:43 AM GMT
potatohead said...
your CPU emulation is an impressive bag of tricks.
Thank you, but at this point I should point out that the tricks were mostly provide by others I just put them in a bag.
To give credit where it is due here is a list of "tricksters" (probably partial and in no particular order):
Bill Henning - Originator of the LMM concept for the Propeller
Phil Pilgrim (PhiPi) - Sugested the reverse execution LMM as used in Propaltair
Hippy - Various suggestions for speedy and small opcode emulation techniques
Rokicki - The SD card routines
Ariba - The wonderful PropTerminal together with PC_Text and PC_Terminal
Sapieha - For some 8080 help
Peter Schorn - For the SIMH Altair simulator, source of all my CP/M bits
Bob Supnik - And all the SIMH contributors simh.trailing-edge.com/contrib.html
Gary Kildal - For CP/M and the PL/M language that kept me employed years ago
And many other who have popped up on this thread with suggestions and encouragement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dr_Acula: Strangely enough I'm having a sleepless night pondering these same questions. Propably comes from eating and drinking to much over Christmas.
I do have a bucket load of 32K RAMS that I could just brute force connect to the Prop with 26 lines but then my SD card interface is gone. Doing the storage serially over the terminal interface may be a lot slower.
Could add some latches to the mix and multiplex the address and data over 16 lines plus controls as an actual 8085 does but that may be way slow.
Could add some shift registers and pump the address out in serial. Sounds slow but what if we used the Props video shifter circuitry to blow it out really fast ? Anyone have any idea how to do that ? I'm not really up to speed on the video shifters yet.
Given that SD card access and memory access need never happen at the same time perhaps we could invent a clever way of sharing those 26 lines between the two. Sounds messy.
Could wait for Leon's Prop + CPLD + RAM board to use to implement one or more of the above options.
I have even considered putting the 8080 program counter into external counters that could be simply and quickly clocked to increment for successive opcode fetches or loaded for jumps. External latches would then hold the data addresses. Also messy but doable with a CPLD.
Parallax is working on a Prop II with a lot more speed and enough internal RAM to make all this unnecessary but I don't think we can wait that long.
Ahhggg ! What to do ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, I ordered an eZ80 development board from Zilog. It was only $75+ and included 1M of flash and 512K of SRAM plus a bunch of other stuff. There's a version of CP/M already made for it that includes SD card access although needs some error checking added. I plan to use oldbitcollector's VT100 terminal program with it maybe mounting the whole thing on a Protoboard if it will fit (I haven't checked the physical fit).
There are some 32K SPI SRAMs (ON Semiconductor's N25S830HA) two of which could make a nice 64K external memory for heater's 8080 emulator. With a 20MHz clock, that's about 2us per access although with simple SPI code, you can only get about a 5MHz clock for about 8us per access. Fancier techniques like using a cog counter for a clock can improve that.
Comments
Anyone actually started working on VT100 for the Prop yet? Can't be that hard to implement
Perhaps it's time to give PropCOMM a serious overhaul and plug AiGeneric into it for 40x24 (or higher) terminal use.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
There are lots of ways to compile that don't involve Microsoft's M80. Indeed, the M80 is probably the slowest option.
The N8VEM group has gone for TASM and various recent packages of files include TASM as well. To create a new eprom image, a number of files need to be compiled together, including CP/M. The easist way to do this is with a batch file, and the whole compilation process takes about 1/2 a second. Then about 10 seconds to program an eprom with a Willem programmer. Then put the eprom in a ZIF socket. All a bit old-school really and the propeller could certainly introduce some efficiencies there.
listing of build-n-38.bat (38 denotes a 38k baud serial version)
tasm -t80 -b xmodem38.asm xmodem.com
tasm -t80 -b loader-m.asm loader-m.bin
tasm -t80 -b dbgmon38.asm dbgmon-n.bin
tasm -t80 -b cpm22n38.asm cpm22n.bin
tasm -t80 -b -fE5 ROMFRMTn.asm ROMFRMTn.bin
tasm -t80 -b rtc.asm rtc.com
rem tasm -t80 -b gmonitor.asm gm.com
tasm -t80 -b format.asm format.bin
copy /B loader-m.bin+dbgmon-n.bin+cpm22n.bin+ROMFRMTn.bin+format.bin+rtc.com+xmodem.com ROMIMAGE.BIN
pause
The cunning bit is the second to last line with copy /b
This combines each of the .bin files created by tasm into one big file. All you need to do is make sure each .asm program has an org entry at the end to make the length a known quantity eg the format program has
.org $04ff ; fill up space so RTC and xmodem in the right spot
.db $00
.end
All the above code is in Z80 but in TASM can do 8080 and a whole bunch of other opcodes. (A great thing about a Table Assembler). A number of the original n8VEM files were 8080 opcodes but I prefer Z80. You can change them back if you like.
If you are building lots of cp/m images for a propeller, you would probably edit them in a text editor on a PC. Then compile with a double click on the batch file. Then get the binary onto the propeller somehow (maybe via an SD card reader/writer). Maybe via custom software in .net through to the propeller. All your simulator needs is the location of that binary and it can start emulating the codes.
I've tried compiling new CP/M images on the board itself but it is slower. M80 is useful for tiny little self contained programs but not for the operating system itself.
So you are free from Microsoft!
Having looked at the code in detail, I am wondering about your twin propeller approach.
CP/M *really* needs 64k of ram. Consider MBASIC. If you load it up then CP/M takes some space, and MBASIC takes some space and then you only have 30k left for the program. Ditto Wordstar - you need some space to put your text!
If I am reading the propeller datasheets right, I think that there is only 32k of ram?
So a solution could be to add a single ram chip. And this is something I've agonised about for years, but I think a single 128k chip (and don't use half the chip) works out better than two 32k chips. A 128k ram chip from futurlec in a DIP package is only $2.90
Hmm - twin propellers or some other solution. I'm brainstorming the various options. I'm going towards one propeller with a ram chip and that emulates the cpu. And another propeller which is the "terminal" propeller - that does the vga screen and keyboard. And an sd card for all the storage, though I'm not sure which propeller that fits in with.
Adding the VT100 compatibility should be quite doable once the hardware is in place. Right now the TRB design is just a TTY interface and adding escape sequence processing, at least for a good portion of the VT100 commands, should be not a problem.
The N8VEM design is quite flexible so you can use SD or CF if you want.· I am building a Disk IO board with IDE and a NEC765A style FDC on it.·· Not everyone wants old style floppy drives but some of the vintage/retrocomputing hobbyists are really "champing at the bit" for a new FDC to recover their legacy data.
One of the really great features of the Propeller is the support for standard serial interfaces.·· That tremendously simplifies the connection with vintage/recomputing/home brew computers since UARTs are standard items in Z80 CP/M environment.
Thanks and have a nice day!
Andrew Lynch
To be a full up CP/M system my 8080 emulator only needs some RAM and a VT100 compatible terminal. The RAM part I was holding off because it was nice to run it on a standard Prop demo board and, well, I'm holding out for the Prop II with lots more RAM.
The VT100 I have not really looked into yet.
Full Z80 emulation seems a bit too much for the Prop. Fortunately CP/M does not need it but some programs do. Is it so that a couple of Z80 instructions is all we need ? If so it might make sense to add those to the emulator.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 12/24/2008 6:18:59 AM GMT
As for full Z80 emulation I have a question and a possible suggestion. How many cogs does the emulator require? If the answer is only one or two then we could use another one or more cogs for the instructions that are unique to the Z80.
Even though you might write something in Z80 opcodes, I don't think unique Z80 opcodes are needed. Looking at some typical code there are only about 20 instructions that are used regularly. All the code I'm using is just 8080 code. Unique Z80 codes like EXX and LDIR don't seem to occur in CP/M or output from other compilers eg basic. Maybe later in the history of CP/M people started adding Z80 opcodes but I suspect there was pressure not to so as to maintain backwards compatability.
Re a Terminal - I've probably added some confusion by not defining this. Many programs will run on a PC and emulate a VT100 terminal. Eg Hyperterminal and Teraterm.
What the N8VEM group is working on is a propeller board that is completely independent of a PC. It has three connectors - a keyboard connecter, vga connecter and an RS232 connector. Another board sends characters and the propeller displays them. But it is very useful to be able to move a cursor around on a screen - that was how wordstar worked and how many games worked. VT100 had a rather large sequence of commands (to change colours, bold, flashing etc), but there is a simpler subset that would just be moving the cursor and maybe bold text. Even colour changes are not that important.
Some people call this a Dumb Terminal. Some call it a Teletype terminal. They were green or orange or white usually - some were colour but that was just before CGA etc came along. Then in the 90s you could get a dumb terminal in a rubbish skip for free. And now they just don't seem to exist any more.
I'm still intrigued by emulating an 8080 on a propeller - it radically reduces the chip count.
Addit - while I was writing this, lynchaj has jolly well just gone and built a terminal and posted a picture of a propeller terminal that is working!
Post Edited (Dr_Acula (James Moxham)) : 12/24/2008 8:25:31 AM GMT
http://forums.parallax.com/showthread.php?p=669027
Andy
Am I reading it right - the thread ended because some sort of private deal was worked out?
I'm thinking a vt100 terminal would be an excellent demonstration of the propeller (as would another prop running CP/M!)
So many things could use a vt100. Basic Stamp. Picaxe. Z80 boards. So many projects use LCD displays, but go much above 20x4 and a propeller plus freebie vga monitor would end up cheaper.
I'm almost wondering about paying someone to do it and then the deal would be that the code would be donated back to the propeller community as open source. I'm not sure what someone would want for that sort of coding. I'm not sure even whether to suggest a number - because someone who is a beginner might look at it and see it as daunting but someone with experience might find it easy.
If the basic emulation software is written using a lookup table additional commands could be added as needed.
I wonder if it is possible to fit everything in one prop with an external 64K ram chip for CPM similar to the Prop6502 project.
{Digging out PropCOMM for a major upgrade...}
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
It really depends on what flavor of CP/M and how it is implemented. Although the Rabbit is Z80 like (which is still one of my favorite processors BTW) there are several differences in the instruction set which could cause a problem with I/O since several instructions were dropped. A good reference I found about the instruction differences is posted on their site at:
http://www.rabbit.com/documentation/docs/manuals/Rabbit2000/UsersManual/rinst3.htm#934577
I guess you'd have to see if any of those op-codes are used in the version of CP/M you want to try.
Robert
Mike
Is this what you had in mind? www.rabbit.com/products/bl1800/
We should probably make a thread for this in the Sandbox as this is interesting,
but we're hijacking the thread.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
However the real "gotcha" which I think you've noticed is some of those unsupported Z80 instructions are also 8080 instructions (IN, OUT) which is a major problem.· Practically all of the CBIOSs I've seen are packed with those instructions.· Also several applications which require patching will not be easily portable.
The idea behind the N8VEM SBC is a standalone unit that runs CP/M from the original sources or very nearly so.· The default software package has a custom CBIOS for its own IO but even that is pretty common stuff. The rest is straight from the Unofficial CP/M webpage DRI sources with little or no modification.· XMODEM5 did need little patch for serial IO but that was about it.· The design is intended to be low cost and use scrap electronic components to keep builder costs to a minimum.
Most true CP/M applications run straight away with no modifications on the N8VEM.· The usual restrictions apply though... any application which accessed unique hardware (formatting utilities, some terminal emulation, etc) will require patching but since the IO is so basic (8250 UART, 8255 PPI) this is pretty simple stuff.
Yes, I personally use TASM and send the binaries over to the SBC using XMODEM but that is just personal style issues.· If you want to use ASM.COM from the formal CP/M distribution it should work.· As before, you'll need patience as a 4 or 8·MHz Z80 will take much longer to assemble the CP/M sources than even an obsolete laptop.· Different builders use different tools.· I believe James prefers MBASIC.· I like straight 8080 assembler myself.
Thanks and have a nice day!
Andrew Lynch
I was able to speed up a Gameboy emulator by a factor of two just by changing the Z80 emulator.
A similar approach could be used with a Propeller as it does have enough registers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Run M80 then L80, and I wrote a simple submit file so you can do all that in one line without having to remember the switches. The switches are mainly there to generate lots of intermediate files which are useful if there is an error. M80 and L80 are out there in the CP/M world.
Z80 mnemonics but they are really 8080 codes.
This little program changes the baud rate. It has a .MAC extension.
; file 38400.mac
; sets baud rate to 38400
; changing from tasm mnemonics - replace all $nn with nnH
; remove . in front of equ
; remove : in equ lines
; must have a CR/LF after END
; use zasm.sub with supersub
; eg supersub zasm myfile (where myfile is called myfile.mac but do not put the
; mac in the instruction - m80 knows it is implied)
; zasm.sub is the following two lines in a text file
;M80 =$1 /Z/C/L/M
;L80 $1,$1/N/E
IO_Y0 EQU 60h
IO_Y1 EQU 68h
IO_Y2 EQU 70h
IO_Y3 EQU 78h
; UART 16C450 SERIAL IS ATTACHED TO THE SECOND IO BASE ADDRESS
UART0 EQU IO_Y1+0 ; DATA IN/OUT
UART1 EQU IO_Y1+1 ; CHECK RX
UART2 EQU IO_Y1+2 ; INTERRUPTS
UART3 EQU IO_Y1+3 ; LINE CONTROL
UART4 EQU IO_Y1+4 ; MODEM CONTROL
UART5 EQU IO_Y1+5 ; LINE STATUS
UART6 EQU IO_Y1+6 ; MODEM STATUS
UART7 EQU IO_Y1+7 ; SCRATCH REG.
UART9600: LD A,80H
OUT (UART3),A ; SET DLAB FLAG
LD A,3 ; = 1,843,200 / ( 16 x 9600 )
OUT (UART0),A ; Set BAUD rate to 38400
LD A,00H
OUT (UART1),A ;
LD A,03H
OUT (UART3),A ; Set 8 bit data, 1 stopbit
ret ; back to CP/M
end
[noparse][[/noparse]screen dump - type the first line and the submit program does the rest. One line compiling!]
A>supersub zasm 38400
SuperSUB V1.1
CP/M V2.2C
A>M80 =38400 /Z/C/L/M
No Fatal error(s)
CP/M V2.2C
A>L80 38400,38400/N/E
Link-80 3.44 09-Dec-81 Copyright (c) 1981 Microsoft
Data 0103 0114 < 17>
45097 Bytes Free
[noparse][[/noparse]0000 0114 1]
CP/M V2.2C
A>
@heater,
A thought.. What if we take two Props (Like I did with my double stack) and
tie them together running your CP/M simulation on one, and my VT100 terminal
on the other? [noparse]:)[/noparse]
I'm putting some connecting lines between my two boards so I can work on
this. Any chance you'll get to an emulation level soon?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
I believe heaters approach of emulating the 8085 in software on the Propeller solves this problem by using the Propeller prototype boards and demo board.· Most of the construction is already done and only limited additions for other devices.· Its a very clean and a reliable long term solution.· However, if you see the original posting, heater points out correctly that the Propeller has 32K RAM and even with the Cog memory you'll be bumping up against the limits of a usable system to run even a stripped down 8085 monitor like the 85SDK debugmon.
For CP/M and general applications though I think it will probably require some sort of additional memory.· Maybe that could be additional serial SRAM or even a parallel SRAM.· CP/M needs at least 48K to be practical although it will run in a minimum of 16K but there is almost no useable TPA.· The overhead of the 8085 CPU emulation·requires some memory so the overall memory requirements could be significant.
Personally, as kwinn suggests I think the combination Z80 with a Propeller for programmable IO is the way to go.· The Z80 handles traditional CPU and parallel memories and peripherals with the Propeller handling all the modern IO like AT keyboard, video, I2C, and the like.· There is a lot of synergy between·a GPCPU and the uC which make a nice compliment.· That's not the first time a general purpose CPU and a uC have married up though.· Practically all the modern computers have numerous uC's and even the original IBM PC had multiple uC's on board such as 8048s, 8042s, and the like.
Thanks and have a nice day!
Andrew Lynch
I'd just like to make the Propeller 8080 emulator status at this time clear:
1. All 8080 instructions are implemented.
2. The actual 8080 emulation is run by a single COG as PASM code.
3. As I ran out of COG space a handful of instructions are implemented as Large Memory Model (LMM) code.
(For those new to this LMM puts PASM instructions into HUB RAM, they are read into COG and executed there one by one, this is somewhat slower but useful for lesser used 8080 op code emulation e.g. DAA.)
4. CP/M runs just fine, DIR, PIP and all and is built from unmodified sources obtained from the SIMH emulator project.
5. Up to 8 floppy drives are emulated on an SD card by some simple SPIN code and the low level SD card drivers from the Propeler FAT file system. The actual DOS FAT layer is not used, after all we have CP/M here.
6. RAM for CP/M is limited to 24Kb within the Prop
7. Console I/O are through serial emulation and I currently use PropTerminal.
8. All this runs on a Prop demo board with SD card added.
9. All CP/M software that I can through at it has worked provided it works within the RAM limitation.
10. Speed is about equivalent to an original 8080.
11. Everything required to run is included in the down loadable ZIP for convienience.
12. Interrupts are not supported, as per SIMH.
13. Code I have writen using the BDS C compiler for CP/M works.
So at this stage it is the equivalent of 24K Altair with floppies but no hard drive.
And what's in the future future? Well more and more that seems to depend on things being done by other CP/M, 8080, Z80 enthusiasts who have turned up here recently and whose efforts I'm looking forward to checking out. But a few things are clear:
1. RAM must be increased to at least 64K. Problem is any kind of external RAM will slow things down. One option is to dedicate a whole Prop to the actual 8080 emulation using as much HUB RAM as possible and external RAM for the higher addresses as a compromise.
2. Hard disk emulation. Up to four 8Mb drives in SD card. This should be very simple.
3. Proper VT100 terminal. I'd like to see a Prop VT100 screen and keyboard emulation as a separate project. I'm sure many would find it useful.
4. Eventually I want to build an Altair lookalike front panel with all the LEDS and switches
With the above we finally arrive at a stand alone CP/M machine that can rebuild it's own operating system.
Up until now I have not ventured into custom hardware solutions for any of the above as it was unlikely that anyone but me would want to build such a thing. So I kept within the confines of a normal Prop demo board. Recently others have come up with things that would help and which people may actually have one day: Leon is working on a Prop CPLD board with some RAM. drohne235 has the Hive multi Propeller design. Then there are the ideas from N8VEM which I have yet to catch up on.
I've only just now caught up with all the posts here over Christmas so are here a few replies to points raised:
As I said above the actual 8080 emulation only uses 1 COG. I have pondered the idea of using multiple COGS for full Z80 emulation but I can't really see how to do it without clobbering the speed whilst handing control and data from COG to COG through the HUB. Perhaps I just haven't worked it out properly yet. Seems adding extra code for LMM execution in a single COG would be just as fast and a lot simpler at the cost of some HUB RAM but we need external RAM anyway.
Also I'm not really into full Z80 emulation. Not much software uses it and it's a lot more work.
Dr_Acula:
Thanks for all you input here re: building CP/M the N8VEM project etc. Its great you alerted me to all the other CP/M activity going on.
That just what PropAltair does. And they are located at COG address zero for rapid indexing, a trick suggested by hippy.
Oldbitcollector:
Actually I've been enjoying this slight thread hijacking. It's great to see I'm not the only one keeping CP/M alive and there's been some great info coming.
The two prop idea is great. Especially if the terminal can be a useful device by itself for other projects. PropAltair has been at "emulation level" for a long time as described above. It's just been waiting for your VT100 terminal [noparse]:)[/noparse] Do you really have that? Can I have a copy ?
Ha! You spotted the insanity in all this. But I'll try to defend the sanity of PropAltair thus:
1. I was already planning a proper CP/M computer using a 8085 and other old time parts I have hanging around when I was diverted by the new shiny Propeller.
2. Using a Prop for the video is a gift from God (Well Chip) in such a venture.
3. I got bored with soldering so soaking up the peripherals into a Prop was the only way to go.
4. Had to learn PASM and the 8080 emulation was my first PASM program as an exercise.
5. Lo and behold, I don't need to bother with the 8085 after all.
6. I wanted to be first to announce the possibility of running code compiled from C on the Prop. Via the BDS C compiler. Not sure but I think I was. If not then I can now be first to introduce Fortran, Pascal, PL/M etc for the Propeller [noparse]:)[/noparse]
Thanks for all your input everyone. (Don't you people have anything better to do over Christmas?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If there is anything you can use from the N8VEM project to help·please do not hesitate to ask!
Thank you very much for all your hard effort!· I much appreciate it!
Thanks and have a nice day!
Andrew Lynch
It's as close as the next thread.. Grab the _VGA version from the propCOMM2 thread.
It's been getting the most attention. Should now support most of the commands you'll need
for cursor control, etc.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Now I have a problem, because believe it or not there is not one VGA monitor or TV in the house !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
two different monitors on my desk, I can't figure out how I lived
without a debug screen. [noparse]:)[/noparse]
I'll try to update the TV version of the VT100 emulation this afternoon.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
Thank you for sharing it. I'm learning volumes this morning!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
A: Nup!
Choices: Eat too much. Drink too much. Or cut code...
Last night I wrote some VB.NET code to automatically download all the useful software to a N8VEM with one keypress. Eg all the files for wordstar, plus mbasic interpreter and compiler etc.
I can now build a N8VEM from scratch in under 45 minutes:
35 minutes for soldering.
3 minutes to program the eprom
3 minutes to download all the software (38400 baud RS232)
BUT - I'll bet it could be even quicker for heater's project, because there are a lot less chips to solder (16 vs 1).
One of the essentials for any computer is a decent text editor. CP/M has many, but they all seem to need more than 24k of memory. The pukka ones like wordstar really need 64k.
This sounds like it could be a bit of a stumbling block. Is there a version 2 of the propeller in the pipeline with more memory?
Or - do you use good old SRAMs (2 32k ones or a single 128k one)? Do you drive the address and data lines directly or do you use serial to parallel like the HC595? Or do you use serial ram chips (not sure how they compare in price)? Or even old drams (which did have less pins?)
Can this emulation spare 26 lines to drive a sram directly?
I'm wondering about 26 lines to an sram, and just two lines for serial. That is 28 lines.
Then use oldbitcollector's rapidly evolving terminal to do the terminal, keyboard, and indeed, use that board to do extra serial eg to a 'printer' serial port via custom vt100 codes. And do sound on the terminal via custom vt100 as well. Even have some of the storage on the terminal?
Just some more musings - I'm not sure of the optimum answer.
As for no VGA in the house, I've got friendly with my local computer store and they are almost giveaways. Not quite completely free, but along the lines of "if you buy this $40 game you can have a couple of CRT monitors for free"
Post Edited (Dr_Acula (James Moxham)) : 12/29/2008 12:53:43 AM GMT
Thank you, but at this point I should point out that the tricks were mostly provide by others I just put them in a bag.
To give credit where it is due here is a list of "tricksters" (probably partial and in no particular order):
Bill Henning - Originator of the LMM concept for the Propeller
Phil Pilgrim (PhiPi) - Sugested the reverse execution LMM as used in Propaltair
Hippy - Various suggestions for speedy and small opcode emulation techniques
Rokicki - The SD card routines
Ariba - The wonderful PropTerminal together with PC_Text and PC_Terminal
Sapieha - For some 8080 help
Peter Schorn - For the SIMH Altair simulator, source of all my CP/M bits
Bob Supnik - And all the SIMH contributors simh.trailing-edge.com/contrib.html
Gary Kildal - For CP/M and the PL/M language that kept me employed years ago
And many other who have popped up on this thread with suggestions and encouragement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I do have a bucket load of 32K RAMS that I could just brute force connect to the Prop with 26 lines but then my SD card interface is gone. Doing the storage serially over the terminal interface may be a lot slower.
Could add some latches to the mix and multiplex the address and data over 16 lines plus controls as an actual 8085 does but that may be way slow.
Could add some shift registers and pump the address out in serial. Sounds slow but what if we used the Props video shifter circuitry to blow it out really fast ? Anyone have any idea how to do that ? I'm not really up to speed on the video shifters yet.
Given that SD card access and memory access need never happen at the same time perhaps we could invent a clever way of sharing those 26 lines between the two. Sounds messy.
Could wait for Leon's Prop + CPLD + RAM board to use to implement one or more of the above options.
I have even considered putting the 8080 program counter into external counters that could be simply and quickly clocked to increment for successive opcode fetches or loaded for jumps. External latches would then hold the data addresses. Also messy but doable with a CPLD.
Parallax is working on a Prop II with a lot more speed and enough internal RAM to make all this unnecessary but I don't think we can wait that long.
Ahhggg ! What to do ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
There are some 32K SPI SRAMs (ON Semiconductor's N25S830HA) two of which could make a nice 64K external memory for heater's 8080 emulator. With a 20MHz clock, that's about 2us per access although with simple SPI code, you can only get about a 5MHz clock for about 8us per access. Fancier techniques like using a cog counter for a clock can improve that.