First thought on an interface (to use Paleolithic DROM)

[barnacle]

Yes, I can see early low-memory routines to write a byte and to lock and unlock the eeprom

Neil

[BigEd]

I'm not sure if this is applicable, but I think it's a warning worth passing on: even a locked EEPROM will go through the write process, which makes it misbehave for reads, if it sees a write.

[barnacle]

Yes, even if the thing is locked, the internal logic does everything except the actual write, including the automated timing delays.

Good point.

Neil

[barnacle]

Thinking about BigEd's suggestion to use A12 as an input to A14... I have made a change on the next board spin to include a jumper to select A14 to either ground or A12, but I'm not convinced it's necessary.

The only real reason to want to use A14 to ground is to use the bottom half of the EEPROM in a linear manner as viewed from an external programmer... once it's in the board, we don't care as it still appears linear to the processor.

A simple way to cope with this is to (externally) program everything in the bottom half also into the top half; a straight copy. The pages simply swap out so the expected code is visible, whichever mode is used. Though you could also use this to hold an extra 8k of firmware, selectable by the mapped link...

Neil

[barnacle]

Bruce, looking at your execute code in V9, I am impressed by the level of sneaky (assuming I understood it correctly).

Code: Select all

        cmp #KEY_GO
        bmi loop_hex	; enter hex value
        beq exec	; jump punched in code
        ...
        org $fffc	; +4
        dw start
exec:	
        dw addr0	; Jump executes BRK which calls addr0

So the BEQ jumps to the BRK vector, executes what it finds there (the zero of addr0, so a BRK instruction) and triggers the break. Which jumps to addr0...

Of course, that's going to dump three bytes on the stack, but as we've never set it, we don't really care.

Neil

[BruceRMcF]

barnacle wrote:

Bruce, looking at your execute code in V9, I am impressed by the level of sneaky (assuming I understood it correctly).

Code: Select all

        cmp #KEY_GO
        bmi loop_hex	; enter hex value
        beq exec	; jump punched in code
        ...
        org $fffc	; +4
        dw start
exec:	
        dw addr0	; Jump executes BRK which calls addr0

So the BEQ jumps to the BRK vector, executes what it finds there (the zero of addr0, so a BRK instruction) and triggers the break. Which jumps to addr0...

Of course, that's going to dump three bytes on the stack, but as we've never set it, we don't really care.

Neil

Yes, saving the three bytes of "JMP addr0" with the two mostly unused bytes above the RESET vector was the sneakiest of the bytes saved. That was developed in two steps, as at first it branched to a different $00 somewhere in the code, but when I realized it could branch to the BRK vector to jump to the address in the BRK vector, that was too slick not to do.

There's a comment when addr0 is specified that it's got to be page aligned, and executing the low byte of the address as BRK is half of the reason (initializing the low byte of memptr with STZ is the other half - there literally isn't room for addr0 to not be page aligned).

And, yes, arbitrary S' = arbitrary S-3, but presumably one of the first things the code at $0200 is going to do is to set S to $FF, so the status register and BRK return address is going to be lost in any event.

[barnacle]

Well, the PCBs for Meso and Paleo arrived. The parts order is on its way, but sadly without the '154 of which they kindly advised me of after posting the rest of the order, so I couldn't substitute, so that's coming from Reichelt.

There's a distressing amount of soldering to be done on Paleo!

And something I came across in the back of a cupboard from over a decade ago... it's remarkable how similar it looks

Neil

[BigEd]

Nice find! Is the story of that SBC told somewhere?

[barnacle]

No, it was never completed. It got me the job designing pet feeders; I took it and a couple of other boards along to the interview, the CE liked it and hired me on the spot. I discovered later he had dozens of BBC micros in his attic...

It's nothing exciting; it used a (now non-available) LED driver and a (now non-available) UART, but - as always - the problem was how to fill the EPROM.

I believe I have now solved that issue, for some values of 'solved'.

Neil

[BigEd]

Great story an unexpected benefit of building your own.

[barnacle]

Rats, turns out that my RAM chips are SOP-24, not SOIC-24. SOIC will fit on SOP, but fitting it the other way around is difficult though _just_possible. Time for PCB v2...

Neil

[barnacle]

Well, the parts have arrived; the processor board is built, and all the sockets have power at the right places.

I haven't put any silicon on it yet, though Maybe tomorrow.

Neil

[barnacle]

Well, there's good news and there's bad news... the LEDs light up and are multiplexing (different each time I power it) but no changes when I reset it, and no response to any keys. It's running from the EEPROM, and taking a healthy 20-40mA depending how many segments light. Which seems fair...

So now I need to do a little investigation, but first I need to do some more work on the electric paraglider winch (the winch is electric, not the paraglider).

Neil

[barnacle]

I haven't got very far yet, but at least (a) the processor is running and (b) the display circuitry is fine. This is just

Code: Select all

main:
	ldy #7			; we have eight leds but we only need to drive six
					; (saves code space)
display:			
	; for each character...
	lda LED_PATTERNS,y
	sta led_addr,y
dla:
	dex
	bne dla			; small delay

	; update the display count
	dey
	bpl display			; back for next digit
	bra main			; reset digit count if required

	org $ffec
LED_PATTERNS	db 0b00111111	;0		; for Meso
				db 0b00000110	;1
				db 0b01011011	;2
				db 0b01001111	;3
				db 0b01100110	;4
				db 0b01101101	;5
				db 0b01111101	;6
				db 0b00000111	;7
				db 0b01111111	;8
				db 0b01101111	;9
				db 0b01110111	;A		; changed to capital
				db 0b00111100	;b
				db 0b00111001	;C		; changed to capital
				db 0b01011110	;d
				db 0b01111001	;E		; changed to capital
				db 0b01110001	;F		; changed to capital
	
	org $fffc
vreset:
	dw init

So the next step is to get the scope fired up and see what's happening to the keypad, and then see if there was a problem with the routine that converted a byte to two bit patterns. The code has been messed around with so much to make it fit Symon's memory model it's possible I've screwed something up there.

Neil

p.s. the multiplexing upset the camera on my phone I think; to the eye the contrast is much better.

p.p.s. the winch now has two motor controllers connected and all of the control logic except the main controller; really just needs the high-current feeds fitting. That's on 70sqmm cable, so it needs a special crimp tool that the owner is trying to borrow...

[barnacle]

I gloat!

Success has crowned my very efforts!

(bonus points if you can identify the source of those quotes without recourse to a search engine )

It's up, it's running the original code, though from an EEPROM, not the diode collection yet. The lack of key response was the size of the anti-bounce capacitor; it didn't have time to get down anywhere near a low so for the time being I've nuked them all; there doesn't seem to be any obvious bounce and a final version needs to be a bit smarter anyway.

(this needs to get close to ground, or at least below half rail!)

The lack of general operation looks as it it were a dodgy solder joint in the RAM - remember, I struggled to fit an SOP part on a (narrower) SOIC footprint.

Now I need to test the execution (it's saving to the ram apparently correctly) and that means I have to write a fairly small program that can e.g. write the LEDs without talking to the original EEPROM. Though I can make use of the to_leds() routine, I guess.

Neil