Topics

MicroDOS Running on Compact Flash


cmdrcosmac
 

Hi, all

This is all seriously preliminary for now, but I now have MicroDOS running out
of a Compact Flash card. The hardware is similar to the Elf2k system.
 The software is inspired by, but not a copy of, Mike Riley's work.

 EMMA 02 was of great help in following RCA's disk code to find what could be changed
and what could not.

 There are still issues at this point. I've not tested all 4 "drives" in MicroDOS,
but they seem to work from UT71's R and W commands. In MicroDOS, DIR and EXAM work.

 I've run into Todd's "Aborted" thing, but since this is on a SuperElf I hold the I key
when needed and the command proceeds. I'll have to find the flag branches.

 The Disk software is still in the " Proof of Concept" stage. It needs to be trimmed to fit.
into 2k. I may be able to free up a register. It still needs error checking.

I chose this way because it would be cheaper, easier to reproduce, and not rely on vintage
media or parts. The interface is only two chips. And the performance is amazing! MicroDOS
loads in under a second. I can't wait to see it run an assembly job.

 The CF card was imaged from the .img file in EMMA.
 
-Chuck


cellarcat
 

Chuck, this is really exciting news. I just successfully blended my MS2000 with the the Elf2K circuits and my computer can now be either an MS2000 or an Elf2K with the flick of a single switch. One of my future goals was to get Microdos running with the compact flash card on the disk expansion board for the Elf2K. Right now I have Microdos running with two 80 track 720K 5.25 inch floppy drives. I have run Microdos with 4 drives and it will recognize them. I had the two floppies attached plus 2 Gotek drives. Do you have a disassembly of op.sys?

 

On May 19, 2020, at 1:56 PM, cmdrcosmac <cmdrcosmac@...> wrote:

Hi, all

This is all seriously preliminary for now, but I now have MicroDOS running out
of a Compact Flash card. The hardware is similar to the Elf2k system.
 The software is inspired by, but not a copy of, Mike Riley's work.

 EMMA 02 was of great help in following RCA's disk code to find what could be changed
and what could not.

 There are still issues at this point. I've not tested all 4 "drives" in MicroDOS,
but they seem to work from UT71's R and W commands. In MicroDOS, DIR and EXAM work.

 I've run into Todd's "Aborted" thing, but since this is on a SuperElf I hold the I key
when needed and the command proceeds. I'll have to find the flag branches.

 The Disk software is still in the " Proof of Concept" stage. It needs to be trimmed to fit.
into 2k. I may be able to free up a register. It still needs error checking.

I chose this way because it would be cheaper, easier to reproduce, and not rely on vintage
media or parts. The interface is only two chips. And the performance is amazing! MicroDOS
loads in under a second. I can't wait to see it run an assembly job.

 The CF card was imaged from the .img file in EMMA.
 
-Chuck


cmdrcosmac
 

 Hi Cellarcat!
 You and Todd were my inspirations. If you have the Elf2K CF card board and Elf/OS this
should be simple. MicroDOS uses a tiny part of the CF card. If you can tell Elf/OS to
use half of the CF card you can mod the MicroDOS CF driver to use the other half.
Or you could reserve part of the card to hold FIG-Forth's screens.
 MicroDOS in fact "thinks" in terms of LBA's, not track and sectors. The LOAD: and
RDISK: routines pass track+sector thru Reg. ASL to SEEKA: It then places them in the IOCB.
CMD: then loads them to the uPD765. SEEKA: is only (AFAIK) used by LOAD: and RDISK:
 MicroDOS seems (so far to me) only  to use READST:/WRITST: These call SEEKST:, which
gets LBA's from PARA and converts them to track+sector, then places them into the IOCB.

 I modded the CMD: routine to convert the track+sector back to LBA. The 2 lowest-order
LBA registers in the CF card are used. The RCA "Unit" value id placed in the hi bits
of the LBA before it's sent to the card. Thus the four floppies are emulated in one
contiguous space in the CF card.

 I don't have any source code other than UT71. i will have to torture EXAM and other
MicroDOS utilities with EMMA02 to find the flag branches that deal with the BREAK key.
Todd's (RCA's) SDI>EF4 trick is impractical on the SuperElf as it uses /EF4 for the I
key.

Best,
-Chuck


David Schultz
 

On 5/19/20 5:48 PM, cmdrcosmac wrote:
 I don't have any source code other than UT71.
While figuring out the hashing scheme used in the MicroDOS directory
structure I ran OP.SYS (MicroDOS) through a disassembler. While
searching for the hashing code I labeled things and added comments. Just
in case I might need to look for something again. So it is kind of like
source code.

You could do that for pretty much any of the .CM files.


--
https://web.archive.org/web/20190214181851/http://home.earthlink.net/~david.schultz/
(Web pages available only at the Wayback Machine because Earthlink
terminated that service.)


cmdrcosmac
 


Hi,
One of the last "known unknowns" I'll need to deal with is the /EF4 BREAK
detection. Do you know if the utilities call serial I/O routines in OP.SYS
or do they have their own routines? Nothing in UT71's serial code seems to
reference /EF4. Thanks.
-Chuck


cellarcat
 

Thanks, Chuck! Your notes are really encouraging because I had feared that OP.SYS might be doing things on its own outside of the routines in UT71. Keep us posted!

On May 19, 2020, at 5:48 PM, cmdrcosmac <cmdrcosmac@...> wrote:

 Hi Cellarcat!
 You and Todd were my inspirations. If you have the Elf2K CF card board and Elf/OS this
should be simple. MicroDOS uses a tiny part of the CF card. If you can tell Elf/OS to
use half of the CF card you can mod the MicroDOS CF driver to use the other half.
Or you could reserve part of the card to hold FIG-Forth's screens.
 MicroDOS in fact "thinks" in terms of LBA's, not track and sectors. The LOAD: and
RDISK: routines pass track+sector thru Reg. ASL to SEEKA: It then places them in the IOCB.
CMD: then loads them to the uPD765. SEEKA: is only (AFAIK) used by LOAD: and RDISK:
 MicroDOS seems (so far to me) only  to use READST:/WRITST: These call SEEKST:, which
gets LBA's from PARA and converts them to track+sector, then places them into the IOCB.

 I modded the CMD: routine to convert the track+sector back to LBA. The 2 lowest-order
LBA registers in the CF card are used. The RCA "Unit" value id placed in the hi bits
of the LBA before it's sent to the card. Thus the four floppies are emulated in one
contiguous space in the CF card.

 I don't have any source code other than UT71. i will have to torture EXAM and other
MicroDOS utilities with EMMA02 to find the flag branches that deal with the BREAK key.
Todd's (RCA's) SDI>EF4 trick is impractical on the SuperElf as it uses /EF4 for the I
key.

Best,
-Chuck


cmdrcosmac
 

Hi Cellarcat,
I believe MicroDOS or the utilities use their own serial routines because UT71 seems
not to reference /EF4, and MPM-241 mentions /EF4 being assigned to the terminal serial.
Also Todd had to hook up /EF4 to the UART to make things work. I found that EXAM will
only finish a page if I hold down the I key on the Super Elf.
 Whether the routines are in OP.SYS or in the EXAM program I don't know.
David Schultz has a disassembly of OP.SYS. Perhaps he could shed some light...
 Also, I haven't figured out how to get EMMA02 to break on an instruction.
That would quickly reveal where the flag branch instruction is.
-Chuck


cellarcat
 

You are right about EF4. The schematic for the 18s605 shows it being hooked up through a 4066 switch to the serial in line from the level converter. The switch is triggered by the UART select line. Actually you have a chice of EF3 or EF4 but UT71 wants EF4. Seems odd that the basic I/O routines would be scattered around outside what is arguably a bios, namely UT71. 

On May 19, 2020, at 9:53 PM, cmdrcosmac <cmdrcosmac@...> wrote:

Hi Cellarcat,
I believe MicroDOS or the utilities use their own serial routines because UT71 seems
not to reference /EF4, and MPM-241 mentions /EF4 being assigned to the terminal serial.
Also Todd had to hook up /EF4 to the UART to make things work. I found that EXAM will
only finish a page if I hold down the I key on the Super Elf.
 Whether the routines are in OP.SYS or in the EXAM program I don't know.
David Schultz has a disassembly of OP.SYS. Perhaps he could shed some light...
 Also, I haven't figured out how to get EMMA02 to break on an instruction.
That would quickly reveal where the flag branch instruction is.
-Chuck


 
Edited

Many MicroDOS utility programs (like COPY) seem to use B4/BN4 to see if the operator has typed anything and, if so, they abort.  I'm not sure that it's actually testing for BREAK specifically; any character input is enough to abort.  It also seems like MicroDOS assumes that all disks are the same capacity, so the only way to use all of a CF card is to break it up into a bunch of floppy sized partitions.   It's also really annoying that MicroDOS wants a 2K EPROM partition right in the middle of memory at 0x8000, with RAM both below AND above that. I looked at running MicroDOS on the Elf2K, and hacking it up to match that memory map is the hardest part.  You can kind of get by with just 32K RAM but some things, like the PL/M compiler, need more.  I'd love to see what you guys have done.


cmdrcosmac
 

I will study again the 18S605 schematic. As well as the Quest SuperElf. Things will be a little more complex
for me as I want to preserve the original function of the Elf's I key. So i will have to work in an OR function.

 Perhaps the I/O routines were included in the various RCA programs because their programmers were not aware of how
the UT-series BIOSes worked, or would later work. Maybe the hardware designers didn't either hence the /EF3-/EF4
select jumpers. As I understand not all of RCA's COSMAC work was done in the same place, toll phone calls weren't
cheap so there was probably a bit of "covering all bases" going on.

 The UT71 designer was constrained by the capabilities of the uPD761. There are the MAXTRK and MAXSEC equates in
UT71 that suggest a bit of flexibility. There are also constraints in the disk filesystem design that might limit
volume size. For now I'm happy with 4- 640k volumes. It appears that UT71's RDISK routine could be modded to
take a max unit no. of F rather than 3. MicroDOS itself might be not so easy.

 I have the CF card set up as LBA addressing using the Sector Number and the Cylinder Low registers. Addressing
the 630 sectors on the disk takes all 8 bits of the Sector Number register plus the 2 lowest bits of the Cylinder
Low register. I get RCA's UNIT value from the IOCB, shift it left twice to get the 2 unit bits into bits 2 and 3,
ANI #0C to zero the rest of the bits, then OR with the Cylinder Low value. This maps all 4x630 sectors into
one contiguous space at the bottom of the CF's address space.

 I initialize an unused byte in the IOCB to 00 and CMD: places that into the CF's Cylinder Hi register.
That way, anything else that wants to use the disk can place a non-zero value there in the IOCB and call the
disk without disturbing MicroDOS's filesystem.

 The EPROM at 0x8000 thing probably arose out of the old RUN-U/RUN-P tradition of holding A15 high at startup
to get to the utility. It might be easier to mod the hardware and software of the Elf2k to suit MicroDOS
than the other way around. Just give the Elf2k 64k of RAM, minus its BIOS, and have Elf/OS load UT71 and
MicroDOS. Then fix UT71's I/O group selection and I/O mapping to match Elf/OS's. Because RCA's programs
do their own thing with the UART, it might be easier to add a UART. You can then patch Elf/OS to use it.
Perhaps fix things so that when UT71 starts it deselects the Elf2k ROM System reset then re-enables the Elf2K ROM.

 Time to get breakfast...
Best,
-Chuck


cellarcat
 

You may be right but I’d still be surprised if there was no engineer in overall charge. The MS2000 could have been a really great little computer. Instead it is a massive kluge. And considering it came out in 1982 there is really no excuse for it other than RCA simply did not care. Bob Armstrong hit the nail on the head with respect to the 8000 start address. That has to change! Ideally UT71 should be at the top of memory as the BIOS, with Microdos right below it a la CP/M.  After that I would say memory banking a la CP/M 3  but there is really no software around to justify it.

Your last paragraph is really what I did with my combo computer. The two computers share the CPU, the control and display circuits (the Elf data display has its own trigger to show the post codes) and the lower 32K of memory. The hardware switch switches the attached I/O on and off and selects the appropriate ROM and upper memory. The Elf has no upper RAM but the MS2000 does. I am also running the RS232 through the MS2000 level shifter in order to use the same DB9 connector for both computers. That could go either way but in my case the MS2000 was a shorter hop with the wire wrap than the Elf circuit. Let’s face it, all 1802 computers share the same CPU and access to memory and have basically the same control and display circuits. It is the memory map and the I/O that distinguishes them and determines what software will run on what computer. Because I am a hardware guy and not very good with software (!) I have always thought about creating a universal computer that would run any 1802 software just by changing the memory map and attached I/O with a switch which could be electronic or hard. That way I don't have to rewrite all the software. This, of course, is the lazy man’s approach catering to what he knows and likes and avoiding having to learn how to program which he really needs to do! My combo computer was an experimental step towards creating a universal computer and it works. The problem is that it simply repeats the shortcomings of the computers it imitates, especially the MS2000. I think the Elf2K is the most sophisticated 1802 computer out there but it is still limited to only 32k. What I really want is to make a 64k Cosmac with the kind of I/O versatility you get with a good CP/M computer. I recently put together a Megatel Quark 100 which has incredibly flexible access to floppy drives all done through software which alters the BIOS parameters. The Ampro LittleBoard is like that too and it adds SCSI to the mix. I get the feeling that we are heading in that direction so maybe some exciting new developments ahead. Time to get lunch!

On May 20, 2020, at 12:10 PM, cmdrcosmac <cmdrcosmac@...> wrote:

I will study again the 18S605 schematic. As well as the Quest SuperElf. Things will be a little more complex
for me as I want to preserve the original function of the Elf's I key. So i will have to work in an OR function.

 Perhaps the I/O routines were included in the various RCA programs because their programmers were not aware of how
the UT-series BIOSes worked, or would later work. Maybe the hardware designers didn't either hence the /EF3-/EF4
select jumpers. As I understand not all of RCA's COSMAC work was done in the same place, toll phone calls weren't
cheap so there was probably a bit of "covering all bases" going on.

 The UT71 designer was constrained by the capabilities of the uPD761. There are the MAXTRK and MAXSEC equates in
UT71 that suggest a bit of flexibility. There are also constraints in the disk filesystem design that might limit
volume size. For now I'm happy with 4- 640k volumes. It appears that UT71's RDISK routine could be modded to
take a max unit no. of F rather than 3. MicroDOS itself might be not so easy.

 I have the CF card set up as LBA addressing using the Sector Number and the Cylinder Low registers. Addressing
the 630 sectors on the disk takes all 8 bits of the Sector Number register plus the 2 lowest bits of the Cylinder
Low register. I get RCA's UNIT value from the IOCB, shift it left twice to get the 2 unit bits into bits 2 and 3,
ANI #0C to zero the rest of the bits, then OR with the Cylinder Low value. This maps all 4x630 sectors into
one contiguous space at the bottom of the CF's address space.

 I initialize an unused byte in the IOCB to 00 and CMD: places that into the CF's Cylinder Hi register.
That way, anything else that wants to use the disk can place a non-zero value there in the IOCB and call the
disk without disturbing MicroDOS's filesystem.

 The EPROM at 0x8000 thing probably arose out of the old RUN-U/RUN-P tradition of holding A15 high at startup
to get to the utility. It might be easier to mod the hardware and software of the Elf2k to suit MicroDOS
than the other way around. Just give the Elf2k 64k of RAM, minus its BIOS, and have Elf/OS load UT71 and
MicroDOS. Then fix UT71's I/O group selection and I/O mapping to match Elf/OS's. Because RCA's programs
do their own thing with the UART, it might be easier to add a UART. You can then patch Elf/OS to use it.
Perhaps fix things so that when UT71 starts it deselects the Elf2k ROM System reset then re-enables the Elf2K ROM.

 Time to get breakfast...
Best,
-Chuck


taf123
 

Hi Chuck and cellarcat -

You guys are seriously taking this to the next level - I like it!

I got a chuckle about holding the "I" button to prevent a BREAK condition.  Instead of pressing the BREAK key, you're pressing the !BREAK key ;-)

Looking at the FORMAT.ASM from the files area, we see that RCA is just checking to see if !EF4 is asserted, meaning that the SPI is a logic 1.  If it's not, then they abort.

L00B5:
    b4    L00C0
    call    UCALL
    db    TYPE
    dw    L0413
    lbr    oloop
;

This isn't a real BREAK condition as this could be caused by any key being pressed, if the ASCII code just happened to be sending a 0 at the time of the !EF4 flag check.

BREAK should be outside of the normal serial data space, so holding the serial line to logic 0 long enough to violate the stop bits and cause a framing error in the UART.

Very interested in how this project pans out.

Regards,
Todd


 

On Wed, May 20, 2020 at 11:21 AM, Bob Armstrong wrote:
I looked at running MicroDOS on the Elf2K, and hacking it up to match that memory map is the hardest part.  You can kind of get by with just 32K RAM but some things, like the PL/M compiler, need more.  I'd love to see what you guys have done.
On Wed, May 20, 2020 at 03:03 PM, cellarcat wrote:
I have always thought about creating a universal computer that would run any 1802 software just by changing the memory map and attached I/O with a switch which could be electronic or hard.
Just curious...  Would a computer design with the capability to load an image into 64K RAM at startup be desirable?  Would the computer need memory mapped I/O as well?


cmdrcosmac
 

A RAM-only system could have specific uses, but as a general-purpose machine it would probably offer no
advantage over the usual OS/Monitor in ROM + some RAM. If you haven't a Monitor or loader available
at startup you're going to get one in somehow. The COSMAC is more amenable to this than most, with its
LOAD mode. But you need extra hardware to push in the code. David Madole wrote a very short loader
that could be toggled into a MC, which would then load a binary. CodeDoctor and others have built
Arduino-based loaders for the MC. Chuck Yakym developed a system that used the parallel port on a DOS
box to load the MC. IMHO, these were all less convenient than having a monitor in ROM. Then you have
control and response at startup, you can load to any address, and monitors usually contain some debugging
routines.

 I opted for the IDIOT monitor. It's at F800 in my system, with a hardware RUN-U/RUN-P arrangement.
The rest of the 64K is RAM. I use IDIOT to load a HEX file of UT71, and that loads MicroDOS from
Compact Flash.
 
 These days, given the availability of large RAM chips, a flexible design would have one 64kRAM, and
two ROM sockets, one of which can handle a 28C256, and the other whatever EPROM or EEPROM contains your
monitor. the 28C256 socket needs a jumper to disable its/WE. Each ROM socket is chip-selected via a
688-based address mapper. Put a jumper on its chip enable so its memory can be disabled entirely.
 Now you have a socket for a main monitor, and you can program something else (FORTH, UT71,etc) into
the other, and adjust the 688 mapping and enable jumpers to locate things where you want and what you
want to come up at RUN-U.

(Note: That 688 mapper is the best piece of COSMAC development since the Q-LED) :-)

-Chuck


cellarcat
 

I agree re the 688’s. I followed Todd’s design for his Mem3 and use a 688 for upper memory addressing for the MS2000. The problem I ran into with the roms was that I wired in two sockets for 28C512 EEPROMS and then discovered that I only had one EEPROM left. I had to use a 27c512 EPROM for the V88 Elf2k monitor and unfortunately it has a different pinout. So now I have three Eprom sockets.  Room to grow! I orderred more 28C512’s but they still have not showed up. 

On May 21, 2020, at 2:04 PM, cmdrcosmac <cmdrcosmac@...> wrote:

A RAM-only system could have specific uses, but as a general-purpose machine it would probably offer no
advantage over the usual OS/Monitor in ROM + some RAM. If you haven't a Monitor or loader available
at startup you're going to get one in somehow. The COSMAC is more amenable to this than most, with its
LOAD mode. But you need extra hardware to push in the code. David Madole wrote a very short loader
that could be toggled into a MC, which would then load a binary. CodeDoctor and others have built
Arduino-based loaders for the MC. Chuck Yakym developed a system that used the parallel port on a DOS
box to load the MC. IMHO, these were all less convenient than having a monitor in ROM. Then you have
control and response at startup, you can load to any address, and monitors usually contain some debugging
routines.

 I opted for the IDIOT monitor. It's at F800 in my system, with a hardware RUN-U/RUN-P arrangement.
The rest of the 64K is RAM. I use IDIOT to load a HEX file of UT71, and that loads MicroDOS from
Compact Flash.
 
 These days, given the availability of large RAM chips, a flexible design would have one 64kRAM, and
two ROM sockets, one of which can handle a 28C256, and the other whatever EPROM or EEPROM contains your
monitor. the 28C256 socket needs a jumper to disable its/WE. Each ROM socket is chip-selected via a
688-based address mapper. Put a jumper on its chip enable so its memory can be disabled entirely.
 Now you have a socket for a main monitor, and you can program something else (FORTH, UT71,etc) into
the other, and adjust the 688 mapping and enable jumpers to locate things where you want and what you
want to come up at RUN-U.

(Note: That 688 mapper is the best piece of COSMAC development since the Q-LED) :-)

-Chuck


 

On Thu, May 21, 2020 at 03:04 PM, cmdrcosmac wrote:
 I opted for the IDIOT monitor. It's at F800 in my system, with a hardware RUN-U/RUN-P arrangement.
The rest of the 64K is RAM. I use IDIOT to load a HEX file of UT71, and that loads MicroDOS from
Compact Flash.
 
Chuck, can I impose to ask what the RUN-U/RUN-P arrangement is and how you use it, please?  Does it have something to do with mapping EPROM into address space at $0000 temporarily during startup?  

My take on a flexible design includes a 64K RAM chip and replaces ROM with a PIC microcontroller Loader / ROM Emulator IC with 128K of flash memory .  The PIC presents to the 1802 (or one of its variants) as a sort of phantom or stealth ROM during startup allowing the 1802 to copy an image from PIC flash memory into RAM memory.  After loading RAM the PIC sets R0 to your start address, disconnects itself from the 1802, and provides a programmable CPU clock and optional ACIA clock. 

To load or update an image in PIC flash memory you need to bring up the system in ROM Emulator mode.  Connect to a terminal via serial on EF3 and Q (9600-8-1-N) and press an EF4 push button (or jumper) during startup.  Use Monitor like commands in ROM Emulator mode to download hex files from the Terminal into RAM memory.  This could be your IDIOT monitor at $F800..$FFFF and MicroDOS at $8000..$87FF.  Provide a startup address ($F800 ???), set the CPU & ACIA clock frequencies, and use a 'flash' command to copy the 32K RAM image at $8000..$FFFF from RAM into flash memory.  The system will use your start address and clock frequencies and automatically load RAM each time you reset or restart the system.

My 4-chip Pocket 1802 design, started in November 2018, was used to develop and test basic ROM Emulator PIC firmware functions but the PIC was undersized (only 16K FLASH) so a new design uses a larger 28-pin PIC18F27Q43 with 128K FLASH.  

Food for thought...


cmdrcosmac
 

Hi Mike,

 The RUN-U/RUN-P thing was inspired by a note in IPSO FACTO Magazine. Which issue, I forget.
But I think I mentioned it in one of my previous posts on here. My design is "inspired"
by Mr.Hill's but he gets the credit for the concept. IPSO FACTO is a goldmine!

 See the attached drawing. Ignore the switches on the inputs and the "light bulb" on the output.
The drawing is a schematic for a logic emulator/designer program.
the /ROM input is the /CS on the IDIOT EEPROM. This is driven by the /P=Q output of the 688 mapper.

  The /M key and /R key go to the keys on the SuperElf. You could use a pullup and button here.
The /R could go to CPU /CLR.
 The /MRD input goes to the CPU /MRD. /MMRD goes to the /OE on all the memory, RAM and ROM.

The OR gate allows the flip-flop to prevent reading the memory. With reading disabled, the CPU
will see only an open bus with all bits pulled hi. This produces repeated SMI instructions, running
in R0, and incrementing the address bus. Soon the address will get to the ROM, and the mapper will
clear the flip-flop, enabling reads. Now the code on the ROM will run.

 The /R key clears the flip-flop to allow reading so the system runs from 0000. The /M key sets the
flip-flop, disabling reads until the /ROM signal clears it so the ROM can be read.

 On a 5-MHz system the run-up time is less than a second.
 If Peter Renaud wants to re-spin his board, this would be a great addition.

-Chuck


Tom C
 

Always nice to hear that IPSO FACTO lives on, still useful ~40 years later!
Tom
(long retired IPSO FACTO Editor and an A.C.E. founding member)

On 5/23/2020 3:21 PM, cmdrcosmac wrote:
IPSO FACTO
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


ajparent1/kb1gmx <kb1gmx@...>
 

The Circuit for Run-U and Run-P also show up in teh RCA MPM203 manual.
Handy!

Allison
----------------------------------
Please reply on list, due to scrapers on groups.IO
private mail gets spam dumped.


Lee Hart
 

Mike McLaren, K8LH wrote:
My take on a flexible design includes a 64K RAM chip and replaces ROM
with a PIC microcontroller /*Loader / ROM Emulator*/ IC with 128K of
flash memory.
If the PIC is there, why not emulate the 1802 as well? I think the code has already been writted to do this. Someone even did it in an 8-pin PIC!

The PIC presents to the 1802 (or one of its variants) as
a sort of phantom or stealth ROM during startup allowing the 1802 to
copy an image from PIC flash memory into RAM memory.
You could also use an EEPROM or flash ROM that the 1802 could read and write itself. That would give it a form of mass storage.

It's trivial to connect banked memory to an 1802. For example, you could connect a 512k byte RAM directly to the 1802 with no other chips. The 3 extra address lines (A16, A17, and A18) go to the N-lines N0, N1, and N2. Now any I/O instructions to ports 1-7 read and write to the banked memory above 64k.

You would need a separate RAM in the lower 64k as well. Then an OUT n instruction would move a byte from bank "n" memory to main memory; and an INP n instruction would move a byte from main memory to bank "n". The lower 16 bits of the address would come from the X register.

If the banked memory was battery-backed up RAM or ROM, you could enable it at CLEAR or power-up to run your initialization code, like RCA's RUN-U or RUN-P.

Just brainstorming :-)
Lee

--
When something bad happens, you have three choices: You can let it
define you; let it destroy you; or you can let it strengthen you.
-- Theodor Seuss Geisel
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com