6502.org

Posted: **Tue Feb 09, 2010 9:54 pm**

BigEd wrote:

(I think it must have been a typo, but I think Daryl's original response had the appearance of throwing down a challenge to reach 16 bytes.)

Cheers
Ed

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

Daryl

Posted: **Tue Feb 09, 2010 9:57 pm**

Thowllly wrote:

I was looking at the docs (because I wondered if it was possible to do LSR status) and noticed that it appears that the code selects 7bit word length, if I read it right. It would be a bit dificult to write a second stage bootloader that couldn't even use load or store opcodes :)

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?)

8BIT wrote:

Don't know where I pulled the 16 from...

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

mdpenny wrote:

Hmm... :idea:

It's occurred to me that there's another way of achieving the same effect, and quite easily, too - especially for those of us with (almost any) 8-bit Acorn kit (and some 32-bit kit, too) :D

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.

kc5tja wrote:

Back when I was toying with the Kestrel-1 design, one ROM concept I had was an optical matrix, where matrix rows were illuminated by LEDs, and columns were detected by photo-diodes.

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

Posted: **Tue Feb 09, 2010 10:16 pm**

BigEd wrote:

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?

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

Posted: **Thu Feb 11, 2010 2:48 am**

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:

Code: Select all

A2 FF .1 LDX #$FF
9A       TXS
B8    .2 CLV
E8    .3 INX
50 FD    BVC .3
DA       PHX
D0 F9    BNE .2
60       RTS
xx FF    DW  .1 ;reset vector

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

Code: Select all

+-----------+
|6502       |
|           |           +----------+
|        CLK|<----------|CLK       |
|           |           |          |
|      D7-D0|--------+  |     Clock|
|           |        |  | (crystal)|
|     A15-A0|======+ |  +----------+
+-----------+      | |
                   | |
+-----------+      | |
|Address    |      | |
|decoding   |      | |
|logic      |      | |
|           |      | |
|          A|<=====+ |
|           |      | |
| ROM SELECT|----+ | |
|           |    | | |
|  SELECT(s)|==+ | | |
+-----------+  | | | |
               | | | |
+-----------+  | | | |
|6522(s),   |  | | | |
|SRAM,      |  | | | |  +----------+
|etc.       |  | | | |  |       ROM|
|           |  | | | |  |          |
|     SELECT|<=+ +-|-|->|SELECT    |
|           |      | |  |          |
|      D7-D0|------|-+--|D7-D0     |
|           |      |    |          |
|          A|<=====+===>|A         |
+-----------+           +----------+

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:

Code: Select all

+-----------+
|6502       |
|           |               +----------+
|        CLK|<-----------+--|CLK       |
|           |            |  |          |
|      D7-D0|--------+   |  |     Clock|
|           |        |   |  | (crystal)|
|     A15-A0|======+ |   |  +----------+
+-----------+      | |   |
                   | |   |
+-----------+      | |   |
|Address    |      | |   |
|decoding   |      | |   |
|logic      |      | |   |
|           |      | |   |  +----------+
|          A|<=====+ |   |  |   Counter|
|           |      | |   |  |          |
| ROM SELECT|----+ | |   +->|CLK       |
|           |    | | |      |          |
|  SELECT(s)|==+ | | |   +==|Q         |
+-----------+  | | | |   |  +----------+
               | | | |   |
+-----------+  | | | |   |  +----------+
|6522(s),   |  | | | |   |  |       ROM|
|SRAM,      |  | | | |   |  |          |
|etc.       |  | | | |   +=>|A         |
|           |  | | | |      |          |
|     SELECT|<=+ +-|-|--+   |          |
|           |      | |  |   |          |
|      D7-D0|------|-+  |   |          |
|           |      | |  /|  |          |
|          A|<=====+ +-< |<-|D7-D0     |
+-----------+           \|  +----------+

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:

Code: Select all

+-----------+
|6502       |
|           |
|        CLK|<-----------+
|           |            |
|      D7-D0|--------+   |
|           |        |   |
|     A15-A0|======+ |   |
+-----------+      | |   |
                   | |   |
+-----------+      | |   |
|Address    |      | |   |
|decoding   |      | |   |
|logic      |      | |   |
|           |      | |   |
|          A|<=====+ |   |
|           |      | |   |
| ROM SELECT|----+ | |   |
|           |    | | |   |
|  SELECT(s)|==+ | | |   |
+-----------+  | | | |   |
               | | | |   |  +---------+
+-----------+  | | | |   |  | Parallel|
|6522(s),   |  | | | |   |  |     port|
|SRAM,      |  | | | |   |  |         |
|etc.       |  | | | |   +--|D8       |
|           |  | | | |      |         |
|     SELECT|<=+ +-|-|--+   |         |
|           |      | |  |   |         |
|      D7-D0|------|-+  |   |         |
|           |      | |  /|  |         |
|          A|<=====+ +-< |<-|D7-D0    |
+-----------+           \|  +---------+

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.

Posted: **Sat Feb 13, 2010 6:03 pm**

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

Code: Select all

cpldfit:  version L.33                              Xilinx Inc.
                                  Fitter Report
Design Name: tinybootstrap                       Date:  2-13-2010,  5:54PM
Device Used: XC95108-15-PC84
Fitting Status: Successful

*************************  Mapped Resource Summary  **************************

Macrocells     Product Terms    Function Block   Registers      Pins
Used/Tot       Used/Tot         Inps Used/Tot    Used/Tot       Used/Tot
8  /108 (  7%) 45  /540  (  8%) 30 /216 ( 14%)   0  /108 (  0%) 14 /69  ( 20%)

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

Posted: **Mon Feb 22, 2010 1:57 am**

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.

Posted: **Mon Feb 22, 2010 2:51 pm**

DaveK wrote:

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.

Posted: **Mon Feb 22, 2010 3:36 pm**

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

Posted: **Sun Jul 26, 2015 12:14 am**

With recent posts concerning bootstrapping I was reminded of this thread

Code: Select all

 ldx #$00
 txs
push_byte
 pha
wait
 cmp data_in 
 beq wait
 lda data_in
 bne push_byte
 rts

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?

Posted: **Sat Feb 09, 2019 8:43 pm**

dclxvi wrote:

22 (untested) bytes is what I came up with. 253 bytes are always sent, which are stored on the stack (!) The order the bytes are stored in memory is the reverse of the order they were sent (!!) The RTS uses the last two bytes sent/pushed to jump to the appropriate place in the routine stored on the stack. RTI could be used instead, if you wanted to set up the flags before jumping.

Code: Select all

FFE8 A2 03    LDX #3
     8E xx xx STX status
     9A       TXS
FFEE AD xx xx LDA status
     4A       LSR
     90 FA    BCC $FFEE
     AD xx xx LDA data
     48       PHA
     E8       INX
     D0 F3    BNE $FFEE
     60       RTS
FFFC E8 FF    DW  $FFE8 ;reset vector

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

Code: Select all

start:
LDX #3
TXS
STX status  ; initialise ACIA
getbyte:
PHA
waitbyte:
LDA status
LSR
BCC waitbyte
LDA data
BNE getbyte
RTS
DCW start ; reset vector

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!

Posted: **Tue Feb 16, 2021 7:29 pm**

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

6502.org

Bootstrapping an SBC

Re: Bootstrapping an SBC

Re:

Re: Bootstrapping an SBC