Yes, it was a typo. I have since corrected it. Don't know where I pulled the 16 from...

Daryl

It would, but it's only the status value which is shifted - and only the bottom bit is tested. After that, the data value is read and stored, unmodified. (Edit: oops, I think you may be referring to the config of the 6850? We've performed a Master Reset, but have we left it in a 7bit mode?)



My theory: a double off-by-one typo for 27.



I think (hope!) any machine with a spare ROM socket can be turned into an EEPROM writer, and that includes the Beeb. It almost includes the electron: perhaps a ROM cartridge can be repurposed.

In my case, I'm interested in booting an SBC as a TUBE-connected parasite, hoping to avoid needing any ROM by using a minimal bootstrap in CPLD. If it doesn't fit, we'll use serial EEPROM but then we won't need to keep it down to a couple of dozen bytes.



Nice idea! Here's an off-topic link to some primitive ROM tech. And another.

Yeah, I meant the config of the 6850. I didn't see anything about what a Master reset actually did, does it set a 8 bit data word size? if it doesn't, is Master reset needed at all? Or maybe Master reset actually sets all the bits exactly as they are needed to be? I was just wondering...

I wouldn't be all that surprised if S=$FF at power up and/or reset was common, but it doesn't appear to be guaranteed, according to sections 3.11 (65C02) and 2.25 (65C816) of the datasheets.

If you could somehow generate a crazy signal with exact enough timing on the SO pin, here's 13 bytes:


Zero bytes might actually be possible. Let's start with a typical 6502 system, as shown in the following ugly text diagram:



You've got the 6502, address decoding logic, a clock, a ROM, RAM, maybe a UART or a 6522, and so on. (In this highly over-simplfied diagram, the non-ROM "SELECT" means any signal(s) like /CS, /OE, R/W, etc. that are needed. Those details aren't important here.)

From the point of view of the ROM, the data bus is an output; that output may be tri-stated (hence the SELECT input), but it's never an input. Every cycle that output will have some value (even though that value may be "don't care").

Let's suppose our RESET handler (located in ROM, of course), merely copies a section of ROM to RAM and then jumps to RAM. Thus ROM is accessed ONLY at RESET and then never again. Since we know the contents of ROM ahead of time, we also know exactly what the address bus be for the first N cycles (when ROM is being accessed) after RESET. So as long as the right data is being output at the right time, the ROM doesn't actually need the address bus (!)

So, let's start by connecting the address bus of the ROM to a counter (which is cleared by RESET) rather than the 6502, (I've also separated the tri-state from the ROM, for reasons which will become clear shortly), like so:



This doesn't accomplish much other than wasting ROM. Before, we only needed two ROM locations ($FFFC and $FFFD) for RESET, and now we need 7 (since RESET takes 7 cycles), five of which are "don't care".

But we can now replace the clock, counter and ROM with a parallel port, like so:



You only need 9 data lines, all of which are outputs. If 8 of the outputs can be tri-stated you may not even need an external tri-state. However, you might want to put a schmitt trigger buffer (or inverter or even a flip-flop) on the clock line, since you definitely do not want ANY glitches there.

Then you just bit bang the bootstrap code in. Get D7-D0 set up, then pulse D8. Obviously, this will be very slooooow, but I don't see a showstopper off the top of my head. I have not tried any of this, of course.

Interesting! Not quite what I need though: I'll have an 8-bit peripheral.

I had a quick attempt to synthesise your 22-byte bootstrap onto CLPD: it comes in pretty small, around 10% of an XC95108. That's quite encouraging, if it leaves room for the glue logic: an SBC containing just a CPU, RAM and CPLD can boot from any byte-wide channel. (Our accelerator board looks a bit like such an SBC - we intended it to be multi-purpose.)


(The above has just OE and 5 address inputs: would need more decode and some means of switching out this mini-ROM after reset.)

Why not buy a Willem programmer? Those are pretty cheap on eBay.

For my first 8085 board I built something with a couple of 4040's that connected to the parallel port. Turned out not to work with the 28C256 I was intending to use so I then used a DS1230 battery-backed SRAM instead.

Can I get a programmer from this site and which one?

http://www.sivava.com/

They are within my price range.

OOH, they have PLCC to DIP adapters too. Cheapest I've seen.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

With recent posts concerning bootstrapping I was reminded of this thread




you can't have consecutive bytes the same or a 0 in the code

edit:
oops goofed it
what's the chance that the accumulator will be 0
comming out of reset?

It looks to me like the combination of the best ideas in this thread ends up somewhat like this:

This is mostly Bruce's plan, pushing the program and then the start address (minus 1), finally using RTS to jump into the code. We save a byte or two by using zero as the terminator, which means we can't have a zero in our loaded bootstrap. But our bootstrap is no longer of constant size, so that's a tad quicker!

Lots of discussion about bootstrapping serially but dclxvi touched on a parallel port bootstrap scheme that's readily applicable to CF disk. At power up the CF disk, by spec, is set to Master Boot Record with sector count of 1. All it needs is a sector read command, wait a bit, then 16-bit words stored in the Master Boot Record will stream out of the data port with every toggle of CF read strobe for next 256 reads. No addressing is needed. A simple state machine can be built to read enable the CF disk and boot off the ensuing FIFO data stream. A true ROM-less bootstrapping method.
Bill