I agree with both of those points. However the OP specifically stated that this concept is designed to help get over the hurdle (perceived or otherwise) of needing to buy an EPROM programmer to build your first SBC. In that context, constructing your own EPROM programmer that requires you to burn an EPROM to construct it is self-defeating since you'll still need to buy an EPROM programmer at some point.

_________________
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Tool-building can be a hobby in and of itself. My late granddad thoroughly enjoyed it.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I tend to agree with BDD...

When starting a new hobby (any hobby), there are some up front costs which should not be avoided. A first system build can be difficult enough for a newbie... add in the complexity of making some tools to program an EEPROM, EPROM or a newer flash device, can easily be beyond the skill set of a newbie.

Consider this.... "is your interest in retro computing to build something from the past, or is it the desire to create the entire infrastructure from scratch?"

From my personal point of view, I prefer to get some good quality tools to start with. This pretty much confirms that when I program an EEPROM or EPROM that the code contained is correct without any doubt. I want to focus on the new project and making it work, not be distracted on figuring out if I have a working hardware scenario that can validate the EEPROM contents that I think I've worked out.

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

In my original post, I wasn't suggesting newbie designing a ROM-less EPROM programmer. It is sufficiently difficult that I was challenging the more experienced designers to come up with a cheap, easy-to-build 6502-based ROMless EPROM programmer. Now, I admit I wasn't clear about what the end product of the challenge looks like. I had in mind a finished, tested design including finished PC board, and have working software all ready to go. I had vision of putting a bare pc board in 1st Class letter mail and ship it cheaply. This way a newcomer can build it as his/her first project and have an useful tool at the same time.

This is really no different than most of my retro designs. The design homepage contains schematic, gerber photoplot, bill of materials, CPLD equations, software, all information needed to build the particular retro project. If I have spare pc boards, I usually offer to ship it free anywhere in USA. I, in fact, have a ROM-less EPROM programmer, but unfortunately it is based on Z280, but take a look at the homepage; it has all information needed to build one. That's what I have in mind for a ROMless 6502-based EPROM programmer project.

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?

Yes, a nice idea to build a tool.

I had a thought about the taxonomy of different approaches to this: with some approaches we'll need a host computer, and with others we won't. For example, if we use a microcontroller, we'll need a host computer to program it and feed it our image. But if we use a front panel, we need no host computer: we can write our bootstrap and our monitor with pencil and paper and hand-assemble it. (Similarly if we rig up our own paper tape or card reader: we can perforate our own tape or cards by hand, or mark them if we've built an optical reader.)

A propeller might be a good choice, if using a microcontroller, because it has a built-in mini-monitor and serial interface. Another good choice might be a teensy board: it's fast enough to emulate an eprom, so you can first load your image into that, to run your eprom programmer, and use it to program up a real eprom, at which point you no longer need the teensy. And because it can act as a ROM, you don't need any RAM-sharing circuitry in your programmer design - it's not a pre-loading approach.

(It might be that the propeller is also fast enough to act as a ROM. But I think it's a 3V part, whereas there are 5V teensys.)

At the risk of demonstrating my ignorance (in both electronics and forum protocol - so apologies if this is deemed off-topic), if a device is fast enough to act as ROM, couldn't it act as RAM too? The Teensy 4.1 has enough pins to interface to the 16 address lines, 8 data lines (and other pins as needed), runs at 600MHz and has sufficient RAM to "feed" the 6502 all its RAM and ROM requirements. The Teensy also has so many other features that the 6502 could utilise. I appreciate the dilemma inasmuch as why not just us the microcontroller in the first place, but personally, I am still not decided between adopting an "old school" approach (6502, RAM, ROM, VIA, memory decoding, clock etc. ) or the use of modern systems for assistance & support.

Also, what is this approach called where a device like the 6502 is "cocooned" by modern support systems? Words like "surrogate", "island", "hybrid" spring to mind but I bet there is a proper term.

Oh, there's no proper terminology for anything, and we could argue all day! And sometimes it feels like we do.

You may well be right, RAM is not a difficult difference from ROM. But RAM chips are cheap enough, so I'm not sure when this would be a great idea. I suppose the Teensy could possibly emulate an EEPROM!

Two things about the Teensy: the 5V-friendly ones are slower. And all of them have rather scrambled pinouts which means shifting and masking, which takes time.

Each of us has to negotiate their own preferences when it comes to what's interesting to pursue - there really is no single answer, however strong one's own feelings might be.

Another thing to consider is the sheer variety of different EEPROM and EPROM devices:

• different capacities
• differnet pinouts
• different physical sizes and package types
• different write-enable algorithms
• different voltages
• in the case of EPROMS, different programming voltages

Making a device capable of programming even a fraction of the different varieties is a non-trivial task. Conversely, if this system was only capable of burning a very small subset of devices it limits its usefulness, particularly if those devices are hard to come by and/or go EOL.

_________________
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.

I'm not so sure it's a big problem, although it does need an answer. The programmer itself surely only needs say 2k of ROM. And the user can decide what their preferred target chip is going to be. By the time they want to change or have to change, they will have the experience to refit, redo, or replace.

Three pages so-far and I've written and cancelled 3 posts so-far...

So 3rd time lucky...



The ROMless boot is the real challenge here. You still need some sort of storage device to hold the run-time code and some sort of "thing" to hold enough code for the 6502 to read that code and start to execute it to give the newbie to ability to program an EPROM.

I've seen desktop PC's used as the storage device, using their parallel port and microcontrollers.

Given the general lack of parallel ports on modern PCs these days then that leaves a microcontroller and so if using a µC, then I'm struggling to see why there is a need for a 6502 at all. You can build up a device uing an Arduino Uno and a pair of 74x595 shift registers that will program popular parallel flash based EPROM devices that can be used in 6502 systems.

A Raspberry Pi could be used too, but then there's the additional issue of setting one up in the first place. It's not hard, but if you're not used to it, then can can sometimes prove a challenge. (Also the 3.3v vs 5v issue too)

So what goes in the 1st class post is an Arduino Uno or compatible, a breadboard, 2 shift registers and some wires. The Arduino can be programmed by the sender or a downloadable ".ino" or .hex file provided to pre-program it.

The code can then take data via its serial line and program the EPROM. You will need software handshake as hardware handshake generally doesn't work on Arduinos although putting the 6502 image inside the Arduino's FLASH to be used to program the device you'll boot the 6502 with is not hard at all - certianly for up to 16KB of target image size. Then subsequently, you design the target 6502 device with a serial port or some other data transfer mechanism - SD/CF, etc. and have it self-program the chip in-situ, just like an Arduino can self program.

The following plans fail the ROMless requirement, but are usable because...

Plan B:

Use a W65C134SXB board.

Develop code for it to allow the user to download the code via it's on-board ROM monitor into it's RAM, use that code to take more code to program into the SST39SF010A Flash device which can subsequently disable the on-board ROM.

A big downside here is the choice of EPROM device - precisely one. It's not a bad choice but PLCC rather than DIL, if that matters.

Plan C: Make a board with the W65C134 CPU and a ZIF Socket for the DIL flash device and as above.

Plan D: Just use the W65C134SXB board and develop your code for that. It has it all.

But the '134 has an on-board ROM. Is that really a problem?




There is a big difference here: The Z280 has an on-board serial port and is designed to be bootstrapped that way. The 6502 doesn't. So... You will need extra glue on the 6502 side plus some sort of ACIA and address generator (and you may well be very clever here and use the 6502 as that), reset that, feed it bytes, write bytes from e.g. $FF00 through $FFFF and take the 6502 out of reset and off you go. You'll need some sort of CPLD/Microcontroller, etc. to assist you with that....

My ROMless Ruby board has the ATmega hold the 6502 in reset, connect to the top 256 bytes of RAM, write a bootloader into it plus vectors then take the 6502 out of reset and wheeeee...

So without a µC in the target system - It's a great idea, but the 6502 is lacking a little. Keep life easy - make a simple programmer for a few popular flash devices that can be used in a modern 65C02 system (e.g. my Arduino one above), then you can concentrate on the target system... Even Ben Eater said you needed a programmer for his popular 6502 system...

Or make the µC an integral part of the target system. I'm now calling it a co-processor in my Ruby boards and it can do stuff like serial, filing system and floating point arithmetics..

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Didn't Ben Eater show how to build one with an Arduino?

It seems to me trying to do this with a ROM-less 6502 based system is not really going to teach a true newbie much about mainstream 6502 use, rather it may fail to teach them esoteric 6502 tricks. Or maybe just confuse them altogether.

Accessibility has always been key to lowering the learning curve. Arduinos are cheap and accessible, especially if the code has already been created.

Edit: Or we could come up with our own board using an Atmel ATMega386 and 2 or 3 74HC595s and use a variant of Ben's code updated for a number of available devices.

_________________
Bill

I agree it's questionable whether the proposed EPROM programmer ought to be 6502-based. But I don't feel that the lack of parallel ports on modern PCs forces us into microcontroller territory.

74x595 shift registers can also be driven from an asynch ("RS232") port. Besides the 595's, what would be on the receiving end is an oscillator and four 74xx chips, as shown below (one each of 'hc4520, 'hc74, 'hc4015 and 'hc132). I like some of the other approaches that were mentioned, including the FTDI FT245, but let's have a closer look at my Dumb Asynch® approach.

The bare PCB mailed to the newbie would accommodate the circuit below plus some as-yet undetermined jumpers and sockets for the (E)EPROM. (And BTW I agree with kernelthread's remark that it'd be good not to rely on memories that require dangerous, magic-smoke-releasing voltages.) The recipient would populate the board and drive it...

• directly from an RS232 port (requires an ancient PC )
• via USB and an inexpensive RS232 converter
• directly from their Arduino/whatever

I'll describe the circuit then note some pros and cons. And it's a work in progress, of course. Years ago I built a Dumb Asynch receiver that lived in a CPLD, but this is my first stab at a discrete logic version. Comments and circuit proofreading welcome.

U2a samples the incoming bitstream at twice the data rate, looking for a Start Bit (which will be a logic high). A high on U2a's output is delayed by shift register U3a, after which it allows U2b to come out of reset and start toggling, and that's what produces SCLK for the 595's. SCLK is shown in the timing diagram; its rising edges reliably sample the data stream despite the variability that's present. U1b counts the trailing edges of the SCLK pulses and sends DONE8 high when 8 pulses are done, resetting U3a immediately then U2a when 2xCLK rises. This completes the reception of one 8-bit byte, whose bits also shift into the string of four 595's.

The bytes are sent in groups of four, and the first byte's LS bit is a "sentinel" bit which must always be a one. When all four bytes are received and properly framed the sentinel bit will appear at Qh of the final 595, causing it to go high. That high gets ingested by shift register U3b, resulting in a logic high pulse that traverses its QA, QB, QC and QD.

When the high pulse appears on QA, this clocks the entire 32-bit frame from the 595 serial registers into the parallel registers; an instant later, SRCLR goes low to clear the serial registers and ensure no false sentinels are subsequently perceived.

As the pulse proceeds to QB, QC and QD of U3b, this is what would trigger the memory operation(s). We have 31 bits of data to work with, which I picture as a 7-bit Control Word along with the intended address and data.

In a bare-bones version, the programmer would be write-only (or at least unable to read and transmit the memory's content back to the host computer). However, it may be sufficient that the user can manually read and verify bytes one at a time, just enough to ensure the circuit is working. For each byte, s/he'd transmit a 4-byte frame with the desired address but with dummy data and a Control Word that calls for a read rather than a write (or maybe the read function would be selected by a jumper option). Then the (E)EPROM's data out could be manually tested one bit at a time using a DMM or logic probe (or LEDs could be included for this).

But if I build one of these for myself -- and I'm tempted! -- I'll wanna be able to transmit the memory's content back to the host. A newbie doesn't require this, but I have some legacy EPROMs I'd like to back up before they start getting as forgetful as I am!

I don't think it would take much to add the readback function. I'd load a '165 or similar parallel-to-serial register, triggered by the pulse off of QD. This would cause a single byte to be transmitted back to the host at the conclusion of every four-byte frame. I'd also need to generate a Start Bit, but overall I expect the amount of extra logic would be minimal (the '165 plus one other chip?).

To summarize, the advantages are low cost, freedom from reliance on any particular OS or manufacturer's tool, and escape from the Catch-22 which Alarm Siren noted (about needing a programmed EPROM in order to build the EPROM programmer!)

-- Jeff
Edit: tweaked diagram and text

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html