Modified to use '74 style flip flops with negative going clear and set; one replaced with a couple of spare NAND gates.
Reset now is normally high, low to reset.
Neil
Yet another sbc without a parallel rom
Re: Yet another sbc without a parallel rom
So, here's a first attempt at turning the Logisim design into an actual 74hc circuit. It lacks things like a clock, reset circuitry, decoupling caps, and, er, the processor part (though the processor bits of my 8153 design should do).
It requires a depressing number of parts - eleven chips and a couple of dozen resistors - and it's going to take up a lot of PCB real estate, but still, it should load the bottom half of a 64kB flash/eeprom into ram from 0xc000 to 0xffff, and the flash/eeprom should easily be programmed in situ (it will probably require a hardware switch to stop the clock). Not sure if I'm going to build this one in the immediate future; I'd like to sort out the STM design next. But I might knock up a limited version on proto strip to prove the timing.
Neil
edit: ack, just realised the ~wp and ~hold pins on the flash are pulled the wrong way. I'll correct that at stage
It requires a depressing number of parts - eleven chips and a couple of dozen resistors - and it's going to take up a lot of PCB real estate, but still, it should load the bottom half of a 64kB flash/eeprom into ram from 0xc000 to 0xffff, and the flash/eeprom should easily be programmed in situ (it will probably require a hardware switch to stop the clock). Not sure if I'm going to build this one in the immediate future; I'd like to sort out the STM design next. But I might knock up a limited version on proto strip to prove the timing.
Neil
edit: ack, just realised the ~wp and ~hold pins on the flash are pulled the wrong way. I'll correct that at stage
Re: Yet another sbc without a parallel rom
barnacle wrote:
I didn't do it that way - I keep the address counter separate from the read generator so that there isn't a permanent offset of three bytes. I want a one-one relationship between the contents of the flash and the eventual contents of the ram.
But yes, you could do it that way as long as your flash loader is aware of that offset. ...
But yes, you could do it that way as long as your flash loader is aware of that offset. ...
I'm putting this note here because I don't have time to nut out that trigger of the end of the 1st stage. Compared to the self-addressed 1st stage bootloader concept I sketched above, I do like that it suits a 128 byte 1st stage as easily as a 64 byte 1st stage, and that it doesn't require pre-processing of the image to be loaded into the first page of the serial FlashROM.
Re: Yet another sbc without a parallel rom
Yes, that should work - might simplify the state machine logic as well. For some reason, I never think of preloading something like a 163...
Wait, though: if you use a preloaded 163, you still only get one bit of address out of the first one in the chain because the bottom three bits are generating the write pulse. So only 32 bytes of loader with a couple of them. Or a 163 followed by a 393 would give you half a kB. I'll have a think about that...
But I suspect if you're going to have to do an OS download anyway, then the 5813 is a simpler approach although possibly a little slower.
Neil
Wait, though: if you use a preloaded 163, you still only get one bit of address out of the first one in the chain because the bottom three bits are generating the write pulse. So only 32 bytes of loader with a couple of them. Or a 163 followed by a 393 would give you half a kB. I'll have a think about that...
But I suspect if you're going to have to do an OS download anyway, then the 5813 is a simpler approach although possibly a little slower.
Neil
Re: Yet another sbc without a parallel rom
barnacle wrote:
Yes, that should work - might simplify the state machine logic as well. For some reason, I never think of preloading something like a 163...
Wait, though: if you use a preloaded 163, you still only get one bit of address out of the first one in the chain because the bottom three bits are generating the write pulse. So only 32 bytes of loader with a couple of them.
Wait, though: if you use a preloaded 163, you still only get one bit of address out of the first one in the chain because the bottom three bits are generating the write pulse. So only 32 bytes of loader with a couple of them.
Edit: The thing I have to still think through is allowing the SBC that it is on to use the same serial shift register to access data from the serial flash, using the SSR on CB2 of a VIA in 8-bit PHI2 clocked output (with the clock on CB1) to provide the read instruction and addressing data to the Serial Flash.
Except for the mutliplex, I think the jelly bean count is 1 USR, 1 '595 SSR, 3 up/down '193 counters, 1 74x00 NAND (two nand gates for an /S /R latch, 1 for filtering system PHI2 into a Stage1 PHI1, one for selecting the FLASH after the USR load is completed), and both sides of a 74x74 clocked d-flipflop -- one is used to create the synchronous load for the USR, the other is used to allow the final byte to be written before releasing the CPU /BE and /RESET, so eight glue logic (though note that the USR's are 20 pin ICs).
Quote:
But I suspect if you're going to have to do an OS download anyway, then the 5813 is a simpler approach although possibly a little slower. ...
Re: Yet another sbc without a parallel rom
BruceRMcF wrote:
... One clocked flip-flop generates the /CPU_BE = /CPU_RESET line which terminates the 1st stage bootloader process when it rises. It is clocked by the /CO pulse of the high address counter, so that the write of the final byte is completed before /CPU_RESET is released. ...
So the /CPU_BE=/CPU_RESET flip flop can be a simple /S /R flip-flop, which can be done in half of a 74x00 ... /RESET_BUTTON and /COUNT3_CO will not both be low at the same time, so the instability of a simple two-NAND gate /S /R flipflop is not an issue, and two free NAND gates is of broad general utility. This flipflop is not speed sensitive, so it is flexible on whether the other two NAND gates need to be fast or shouldn't be too fast to avoid a race.
The sharing of the Flash is something like a '241 tri-state octal driver, with four outputs on active low /1OE and four on active high 2OE. A 74ABT241 seems to be available in DIP and accepts TLL input levels, so can be driven by a 3.3V serial Flash.
/DRIVE_1OE := /BE ; low during 1st stage bootload
DRIVE_1A1 := /1ST_FLASH_SELECT
DRIVE_1Y1 =: DRIVE_2Y4 =: -DIODE+ =: /FLASH_SELECT := pullup+3.3V
DRIVE_1A2 := 1ST_SCLK
DRIVE_1Y2 =: DRIVE_2Y3 =: -DIODE+ =: FLASH_SCLK := pullup+3.3V
DRIVE_1A3 := 1ST_MOSI
DRIVE_1Y3 =: DRIVE_2Y2 =: -DIODE+ =: FLASH_DIN := pullup+3.3V
DRIVE_1A4 := FLASH_DOUT
DRIVE_1Y4 =: 1ST_MISO
DRIVE_2OE := /BE
DRIVE_2A1 := FLASH_DOUT
DRIVE_2Y1 =: SPI_MISO
DRIVE_2A2 := SPI_MOSI
DRIVE_2A3 := SPI_SCLK
DRIVE_2A4 := /SPI_FLASH_SELECT