6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 1:01 pm

All times are UTC




Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Tue Feb 09, 2010 9:54 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1668
Location: Sacramento, CA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 09, 2010 9:57 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Feb 09, 2010 10:16 pm 
Offline

Joined: Wed Oct 22, 2003 4:07 am
Posts: 51
Location: Norway
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...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 11, 2010 2:48 am 
Offline
User avatar

Joined: Thu Mar 11, 2004 7:42 am
Posts: 362
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:
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:
+-----------+
|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:
+-----------+
|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:
+-----------+
|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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Feb 13, 2010 6:03 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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:
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.)


Last edited by BigEd on Sat Dec 07, 2019 3:20 pm, edited 3 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 22, 2010 1:57 am 
Offline

Joined: Sat Aug 30, 2008 11:12 pm
Posts: 34
Location: Kent, UK
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 22, 2010 2:51 pm 
Offline

Joined: Wed May 20, 2009 1:06 pm
Posts: 491
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 22, 2010 3:36 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
OOH, they have PLCC to DIP adapters too. Cheapest I've seen.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Bootstrapping an SBC
PostPosted: Sun Jul 26, 2015 12:14 am 
Offline

Joined: Tue Nov 18, 2003 8:41 pm
Posts: 250
With recent posts concerning bootstrapping I was reminded of this thread


Code:
 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?


Top
 Profile  
Reply with quote  
 Post subject: Re:
PostPosted: Sat Feb 09, 2019 8:43 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
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:
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:
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!


Top
 Profile  
Reply with quote  
 Post subject: Re: Bootstrapping an SBC
PostPosted: Tue Feb 16, 2021 7:29 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1065
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: