I went this route for my first ever SBC.

I have an arduino controlling the bus via BE, and writing my system firware to RAM. I can feed a "ROM" image via USB from my PC, so developing is extremely fast.

I have a script that assembles the "ROM" and sends it to the arduino. When the Arduino gets the first byte, it takes control of the bus with BE, writes the RAM, releases the bus afterwards, the then resets the 6502.

It wasn't too hard to be honest.

It's good to hear that people - even newbies - have successfully taken the path of using a microcontroller to pre-fill RAM, and so avoided the need to program up an EPROM (or EEPROM, which would be just as handy.)

What we haven't seen yet in this thread, I think, is a response to the subject line and the head post:
Design challenge: 6502-based EPROM programmer
and it would be good to see that.

Mouser have some 45ns SST39SF010 128Kx8 for just over £1 each (or 92p each for 10), but they're PLCC32. There are loads of 45ns Winbond W27C512 64Kx8 chips around on ebay for a similar price, but they need 14V/12V to erase/program. When building your own programmer, having 14V around gives lots of opportunities to let the magic smoke out, especially if you want to support multiple pinouts (e.g. the PLCC versions of SST39SF010 and W27C512 have incompatible pinouts).

Regarding the title of this thread, there's this project: https://www.ecstaticlyrics.com/electron ... rogrammer/
That uses a Z80, but maybe it could be modified to use a 6502 if anyone was interested in doing so.

USB-to-parallel interface is a real possibility. I bought one few years ago, I need to dig it out and see how to build a ROMless 6502 with it.
Bill

I will see if I can find my AVR "Romulator" code and post it here.
What it did was allow any of the 40 PIN 8 bit AVRs to "directly" replace a ROM in a slower (<2Mhz) 6502 system.

I wrote a very tight assembly routine that just sent out bytes from the AVR internal eeprom (program memory) based on what it was seeing on the address lines (16 bit).

This $2.00 solution could emulate any rom from 1K to 64K and be inserted into a 6502 system directly. I originally did the project to try some ROM mods on a VIC-20 and PET. It was nice to be able to simply plug in my cheap in circuit programmer and instantly alter the ROMs, sometimes even with the system running!

I know the silicon is certainly more advanced than most of the other retro parts in the system, but in this case, it is only emulating ROM... address in, data out.
Drop a sticker over the 40 Pin DIP IC and call it "ROM V2.2" or whatever, and it won't even look like a modern part!

Costs for this solution in CAD...

- AVR large enough to directly emulate a 32k ROM : $7.00
https://www.digikey.ca/en/products/detail/microchip-technology/ATMEGA324A-PU/2271034

- Programmer for all AVR devices : $160.00
https://www.digikey.ca/en/products/detail/microchip-technology/ATATMEL-ICE-BASIC/4753381

You can also build a multitude of cheap (<$20.00) AVR programmers that would work, or just use an Arduino.
The "ICE" is great since it can program all of the devices from Atmel/Microchip.

I will post the AVR Romulator as a project when I have time. It includes PC software that can take any assembled binary (from one of the 6502 assemblers) and push it right to the AVR through the in-circuit programmer.

Actually, I will be using this solution on a current project, adding a wedge to the PET 2001 system ROM to allow some extended basic commands. WIll take some photos of it working.

The only downside to this solution is that it won't work over 2MHz unless you go up to the XMega series, but those are not DIP packages.

Brad

Thinking about the small CPLD bootstrap code in CRC65, it occurs to me that manually toggle in 6502 opcode may not be too bad of a solution for the simple EPROM programmer. We know all about manually entering the opcode on the front panel, but the difference here is there are no switches for addresses. I'm relying on 6502 to generate the addresses and write the manually entered opcode into RAM at the appropriate addresses while 6502 is also executing the manually entered instruction. Here is a trial balloon design:

W65C02
RAM at 0x9000-0xFFFF
6551 at 0x8000-0x8FFF
EPROM at 0x0-0x7FFF <-- Yes, I know page zero is in EPROM, but hear me out...
1.8432MHz clock
----------------------------------
8 switches on data bus to force data high or low,
switch to disable RAM output enable and enable RAM write enable
debounced switch to single step clock
reset switch

At first power, RAM is set to write always, but its output enable is disabled; clock is driven with debounced single step switch. This is the program I want to manually enter:


This program loads 256 bytes of bootstrap starting from location 0x9012 which is at the end of this program

Once the program is manually entered, reset 6502, set RAM to normal, set clock to 1.8432MHz and release reset. 6502 will execute the same sequence of instructions EXCEPT the branch instructions. There are two branches, 1), testing the serial data received full, and 2), X register equals 0. I can force the program to take serial data receive full branch by sending a serial data to ACIA while manually entering the opcode; I don't need to force the X register equals to 0 because that's the end of manually entered program and where the serially loaded program starts.

Why is EPROM locates in 0x0-0x7FFF? Because I don't want newbie to pay for the ridiculously expensive EEPROM when fast SST39SF010 is $1.50. Programming SST39SF010 requires address 0x2AAA and 0x5555 map to EPROM to enable software command sequences. Not having Zero page may mean self-modifying code for the EPROM programming software, however

By my count, 20 manual entries are needed, not too bad if it only need to be entered a few times, but the poor sucker who designed and debugged this (i.e., yours truly) will regret ever thought of this idea!

Bill

Edit:
Thinking it over, I see there are potential complexity due to some opcode may take more instruction cycles to execute before fetch next opcode. Depending on how messy that turned out, the fall-back method is separating RAM data bus from CPU data bus with a bidirectional buffer (74245) and pull CPU data bus to the NOP instruction value (0xEA), and change the bootstrap code starting location to 0xEAEA. So after reset 6502 fetches 0xEAEA as the reset vector and starts fetching instructions from 0xEAEA. 6502 will continue to execute NOP while the front panel switch values are written into successive locations of RAM. This takes extra buffer and 8 resistors, but is a more generic solution.

Nice idea! Do we know if EEPROMs' unlocking sequence is very timing sensitive?

I suppose there's two kinds of 6502-based EPROM programmer: the kind which itself needs a ROM or an EPROM, and the other kind. For convenient long term use, it would be the first kind. For strict retro bootstrapping, it would be the second. For not-so-strict retro bootstrapping, it can be the second kind but with a microcontroller to load RAM.

Another thought, which is the first kind in a way, is to fit an EPROM-programming-interface to an existing 6502 retrocomputer, whether a Beeb, PET, C64 or other. The host machine already has firmware and I/O and maybe even a filing system, and just needs to drive the machinery appropriately.

For a ROMless 6502-based EPROM programmer, we certainly need a front panel or an unconventional bootstrap. We've had threads before on those topics (Edit: see this post and following). The OSI-300 kind of design might be worth a look - see here.

I wonder if you could use one of the FTDI FT245 Serial devices to stream in machine code...

Just thinking out loud here:
1. Send data down to the FT245 via USB. That data is a small bootloader which has to fit inside the 128 byte FIFO of the FT245.
2. The RXF# output of the FT245 can be used to "release" the 6502 from reset.
3. The FT245 is aliased to the 128-bytes at the top of the address space so that any read in that space accesses the FT245, but this only happens after VP# is pulled low, so that the reset sequence's reads don't clobber our program (or, alternatively, we simply provide sufficient dummy bytes in the FIFO that it doesn't matter).
4. The reset vector is read out of our FIFO, and we jump, again, to somewhere else within that 128-byte window.
5. Execution proceeds linearly, reading a byte at a time out of the FIFO and we can set up a small program elsewhere in memory and jump to that. If we're feeling really brave we could even backtrack somewhere earlier in the 128-byte window if we need to load more data - so long as we can keep feeding the FIFO quickly enough.
6. That new program in RAM flips a bit somewhere that triggers a remap of the 6502's address space, so that the top 128-bytes no longer map to the FT245 (or, at least, the vectors don't).
7. Our new bootloader in RAM can send a signature out via the FT245 to signal its alive and ready to accept more data to be loaded into RAM.

I would predict that for reliable operation there would need to be some glue logic which monitors/controls RESET#, VP#, RXF# and whatever effects the address re-mapping.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

128 bytes might just be enough... no looping though. Could be tight!

Absolutely, but its only got to be enough to put a small program loop elsewhere in RAM which can then load further program data out of the FT245 at a more leisurely rate.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Bill (and gang):

I understand the "cheap" and "easy to build" part of the challenge but why the "no programmable components" qualifier? Is it because the cost of a commercial EPROM programmer may be a barrier for some newcomers?

I believe the $60 commercial EPROM programmer is indeed a psychological barrier to newcomers. It is a specialized tool and newcomers may not recognize it as a critical enabling tool or unwilling to invest in the tool when they are not sure if retrocomputing is really what they want to do. My observation is newcomers tend to focus on retro hardware such as CPU, memory, logic, and peripherals and skip over critical tools like logic probe, scope, power supply, and EPROM programmer. They are likely to spend hundreds of dollars on parts before getting a decent power supply or scope. I'm not passing judgement on what newcomers focusing on; I think it is human nature to focus on the "meat" of a new hobby and only pay attention to tools and supporting infrastructure much later. By proposing a 6502-based EPROM programmer, I'm trying to move the boring tool (an EPROM programmer) into the "meat" section that newcomers focus on.
Bill

Also, if you've already bought an EPROM programmer to program the EPROM of your 6502-based EPROM programmer.... why build a 6502-based EPROM programmer when you already have a functioning EPROM programmer?

There's very little point in building your own EPROM programmer if you need and have purchased an EPROM programmer to allow you to build your EPROM programmer.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Why climb a mountain? Maybe the challenge?

One might argue there is very little point in doing anything with an 8-bit CPU these days, but we do it anyway.

_________________
Bill

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?