Salvage computing, new retro computers from used eBay parts

[plasmo]

Did little more experiments with CPU clock. Proto65 ran reliably with 18.4MHz clock; the mandelbrot benchmark took 62 seconds to run. At 20.28MHz the mandelbrot started to print gibberish and quit half way. 18.4MHz is too close to edge for comfort, so the normal clock is set at 14.7MHz with serial port set at 115200 N81.

4 wait states are added to the IDE access by negating the RDY signal for 4 clocks. IDE needs setup time before write or read strobes, so two clocks (140nS) are for setup and 2 clocks for read/write strobes.

With IDE working, I have modified the bootstrap ROM to enable dual boot; the ROM program loops on serial data received or DOM not-busy. If a serial input is received, it will jump to a serial load routine waiting for 256 bytes of serial data before executing the serially uploaded program; if DOM is not busy, then it will load 256 bytes of data from DOM's Master Boot Record and execute. DOM (as well as CF disk) requires about 1/2 second to initialize before negating its busy flag, so that gives enough time to press a key if serial bootstrap is desired. The ROM program size grew to 64 bytes now which is still small enough to fit in the CPLD with enough logic left for VGA video, I hope.

Now I need to write a serially loadable utility program that writes DOM bootstrap program into Master Boot Record and also puts EhBASIC somewhere in the DOM disk. This way Proto65 can bootstrap by first load & execute the program in Master Boot Record which, in turn, load and execute EhBASIC. Well, that's the plan anyway...

Code: Select all

000000r 1               SerData = $eff9		;CPLD serial register
000000r 1               SerStat = $eff8		;CPLD serial status, bit 0 is receive ready, bit 1 is txempty
000000r 1               CFdata	= $ee00    	;CF data register
000000r 1               CFerr	= $ee01    	;CF error reg
000000r 1               CFsectcnt	= $ee02    	;CF sector count reg
000000r 1               CF07	= $ee03   	;CF LA0-7
000000r 1               CF815	= $ee04       	;CF LA8-15
000000r 1               CF1623	= $ee05       	;CF LA16-23
000000r 1               CF2427	= $ee06       	;CF LA24-27
000000r 1               CFstat	= $ee07       	;CF status/command reg
000000r 1               
000000r 1               	.ORG $ff80
00FF80  1               readbsy:
00FF80  1  AD F8 EF     	LDA SerStat	;check receive ready
00FF83  1  29 01        	AND #1		;receive ready is bit 0
00FF85  1  D0 1F        	BNE serboot	;if serial data ready, do serial bootstrap
00FF87  1  AA           	TAX		;initialize X to zero
00FF88  1  AD 07 EE     	LDA CFstat	;read CF status
00FF8B  1  2A           	ROL		;busy bit is bit 7
00FF8C  1  B0 F2        	BCS readbsy	;loop until either CF ready or received serial data
00FF8E  1  A9 20        	LDA #$20	;issue read CF command
00FF90  1  8D 07 EE     	STA CFstat
00FF93  1               chkdrq:
00FF93  1  AD 07 EE     	LDA CFstat	;check data request bit set before read CF data
00FF96  1  29 08        	AND #8		;bit 3 is DRQ, wait for it to set
00FF98  1  F0 F9        	BEQ chkdrq
00FF9A  1               getCFdata:
00FF9A  1  AD 00 EE     	LDA CFdata
00FF9D  1  9D 00 B0     	STA $b000,x	;get 256 bytes of data to $b000
00FFA0  1  E8           	INX
00FFA1  1  D0 F7        	BNE getCFdata
00FFA3  1  4C 00 B0     	JMP $b000
00FFA6  1               serboot:
00FFA6  1  AD F9 EF     	LDA SerData	;discard the first serial data
00FFA9  1               serboot1:
00FFA9  1  AD F8 EF     	LDA SerStat
00FFAC  1  6A           	ROR		;receive ready is bit 0
00FFAD  1  90 FA        	BCC serboot1	;if serial data ready, do serial bootstrap
00FFAF  1  AD F9 EF     	LDA SerData
00FFB2  1  9D 00 B0     	STA $b000,x
00FFB5  1  E8           	INX
00FFB6  1  D0 F1        	BNE serboot1
00FFB8  1  4C 00 B0     	JMP $b000

[floobydust]

Nice to see such quick progress on your project. Regarding EhBasic, I worked on a CMOS version back in 2018 and have kept it up to date with patches from Klaus. It's smaller than the standard version (<10KB), has some hooks for exit, load and save (via my Monitor which supports Xmodem-CRC16) and has some minor performance improvements as well. It also uses less Page Zero space, which is contiguous versus fragmented.

viewtopic.php?f=5&t=5760&start=15#p76030

[plasmo]

floobydust wrote:

Nice to see such quick progress on your project. Regarding EhBasic, I worked on a CMOS version back in 2018 and have kept it up to date with patches from Klaus. It's smaller than the standard version (<10KB), has some hooks for exit, load and save (via my Monitor which supports Xmodem-CRC16) and has some minor performance improvements as well. It also uses less Page Zero space, which is contiguous versus fragmented.

viewtopic.php?f=5&t=5760&start=15#p76030

Great! I don't have a monitor (yet) so I can only boot straight into EhBASIC, but having an exit function to return to a monitor is highly desirable. I also have wondered whether EhBASIC 'load' & 'save' functions existed and can be modified to load/save from disk. There are so much here that I've not yet explored.
Bill

[maded2]

plasmo wrote:

Did little more experiments with CPU clock. Proto65 ran reliably with 18.4MHz clock; the mandelbrot benchmark took 62 seconds to run. At 20.28MHz the mandelbrot started to print gibberish and quit half way. 18.4MHz is too close to edge for comfort, so the normal clock is set at 14.7MHz with serial port set at 115200 N81.

4 wait states are added to the IDE access by negating the RDY signal for 4 clocks. IDE needs setup time before write or read strobes, so two clocks (140nS) are for setup and 2 clocks for read/write strobes.

With IDE working, I have modified the bootstrap ROM to enable dual boot; the ROM program loops on serial data received or DOM not-busy. If a serial input is received, it will jump to a serial load routine waiting for 256 bytes of serial data before executing the serially uploaded program; if DOM is not busy, then it will load 256 bytes of data from DOM's Master Boot Record and execute. DOM (as well as CF disk) requires about 1/2 second to initialize before negating its busy flag, so that gives enough time to press a key if serial bootstrap is desired. The ROM program size grew to 64 bytes now which is still small enough to fit in the CPLD with enough logic left for VGA video, I hope.

Now I need to write a serially loadable utility program that writes DOM bootstrap program into Master Boot Record and also puts EhBASIC somewhere in the DOM disk. This way Proto65 can bootstrap by first load & execute the program in Master Boot Record which, in turn, load and execute EhBASIC. Well, that's the plan anyway...

Code: Select all

000000r 1               SerData = $eff9		;CPLD serial register
000000r 1               SerStat = $eff8		;CPLD serial status, bit 0 is receive ready, bit 1 is txempty
000000r 1               CFdata	= $ee00    	;CF data register
000000r 1               CFerr	= $ee01    	;CF error reg
000000r 1               CFsectcnt	= $ee02    	;CF sector count reg
000000r 1               CF07	= $ee03   	;CF LA0-7
000000r 1               CF815	= $ee04       	;CF LA8-15
000000r 1               CF1623	= $ee05       	;CF LA16-23
000000r 1               CF2427	= $ee06       	;CF LA24-27
000000r 1               CFstat	= $ee07       	;CF status/command reg
000000r 1               
000000r 1               	.ORG $ff80
00FF80  1               readbsy:
00FF80  1  AD F8 EF     	LDA SerStat	;check receive ready
00FF83  1  29 01        	AND #1		;receive ready is bit 0
00FF85  1  D0 1F        	BNE serboot	;if serial data ready, do serial bootstrap
00FF87  1  AA           	TAX		;initialize X to zero
00FF88  1  AD 07 EE     	LDA CFstat	;read CF status
00FF8B  1  2A           	ROL		;busy bit is bit 7
00FF8C  1  B0 F2        	BCS readbsy	;loop until either CF ready or received serial data
00FF8E  1  A9 20        	LDA #$20	;issue read CF command
00FF90  1  8D 07 EE     	STA CFstat
00FF93  1               chkdrq:
00FF93  1  AD 07 EE     	LDA CFstat	;check data request bit set before read CF data
00FF96  1  29 08        	AND #8		;bit 3 is DRQ, wait for it to set
00FF98  1  F0 F9        	BEQ chkdrq
00FF9A  1               getCFdata:
00FF9A  1  AD 00 EE     	LDA CFdata
00FF9D  1  9D 00 B0     	STA $b000,x	;get 256 bytes of data to $b000
00FFA0  1  E8           	INX
00FFA1  1  D0 F7        	BNE getCFdata
00FFA3  1  4C 00 B0     	JMP $b000
00FFA6  1               serboot:
00FFA6  1  AD F9 EF     	LDA SerData	;discard the first serial data
00FFA9  1               serboot1:
00FFA9  1  AD F8 EF     	LDA SerStat
00FFAC  1  6A           	ROR		;receive ready is bit 0
00FFAD  1  90 FA        	BCC serboot1	;if serial data ready, do serial bootstrap
00FFAF  1  AD F9 EF     	LDA SerData
00FFB2  1  9D 00 B0     	STA $b000,x
00FFB5  1  E8           	INX
00FFB6  1  D0 F1        	BNE serboot1
00FFB8  1  4C 00 B0     	JMP $b000

hi,
can you share your CPLD code, like to learn from your work.

thanks,
eddie

[plasmo]

maded2 wrote:

hi,
can you share your CPLD code, like to learn from your work.

thanks,
eddie

I'm happy to explain my CPLD design. My CPLD design method is a bit unconventional, however. Because I want to have tighter control over the scarce CPLD resources, I have designed it mostly in schematic. The boot ROM is an exception because it is a lookup table so it is designed in Verilog. For your reference, attached is the top schematic of my CPLD. It is drawn with Altera Quartus's schematic entry tool converted to PDF. I can elaborate more if you are comfortable with that design method.

I've reached the end point of Proto65 rev0.1 (I'll talk about that later) so I'm documenting the rev0.1 design in a new homepage. You can find the full CPLD design there. https://www.retrobrewcomputers.org/doku ... proto65r01
Bill

[plasmo]

I am successful in booting from the DOM disk into EhBASIC. I've created an utility program that copies EhBASIC previously loaded in memory from 0xC000-0xEDFF into DOM's track 0, sectors 0xE0-0xF7; the same utility program also copies a bootstrap program into DOM's Master Boot Record. This bootstrap program is executed on next power up and restores the stored EhBASIC program back to memory and then execute. The utility program is rough and needs much better user interface, but it is working.

At this point, I've reached the end of Proto65 rev0.1 development. Its goal was adding a mass storage and having the ability to bootstrap from the mass storage. I'm facing with several options on this New Year Day 20201; (1), I can work on a monitor for rev0.1 to shed much needed visibility to the inner workings of rev0.1 hardware; or (2), I can plow ahead with rev0.2 development which is adding VGA/keyboard capability; or (3), I can capture the rev0.1 and the planned rev0.2 designs and layout a pc board. In a nutshell, (1) is what I SHOULD do, (2) is what I WANT to do, and (3) is INSURANCE in case I screwed up (2).

Well, I'll give myself a day to think about this, but meanwhile rev0.1 design is documented here in a new homepage: https://www.retrobrewcomputers.org/doku ... proto65r01

Bill

PS, INSURANCE, meh, today is "Of all the glad new-year, mother, the maddest, merriest day".

PPS, Happy New Year!! As of today, all hind-sights are "2020"

[plasmo]

plasmo wrote:

I'm facing with several options on this New Year Day 20201; (1), I can work on a monitor for rev0.1 to shed much needed visibility to the inner workings of rev0.1 hardware; or (2), I can plow ahead with rev0.2 development which is adding VGA/keyboard capability; or (3), I can capture the rev0.1 and the planned rev0.2 designs and layout a pc board. In a nutshell, (1) is what I SHOULD do, (2) is what I WANT to do, and (3) is INSURANCE in case I screwed up (2).

Having thought about the three options, I decided on option (4), have FUN!

There are two spare I/O pins remained on the prototype area, just enough to make an I2C interface. I still want to reserve most of my remaining CPLD resources for video, so I created an new I/O address, 0xEFF0 and added two flip flops, one drives the SDA signal and other drives SCL signal of I2C bus. Another word, a minimalistic bit-bang I2C interface.

Physically, I added a 4-pin header with pin assignments match that of 128x64 OLED display widely available on eBay.

Algorithmically I've done 128x64 OLED display with Z80 assembly, so it is a matter of porting Z80 code to 6502 which is a good exercise in learning 6502 assembly. Addressing table using a 16-bit pointer on zero page is definitely a new concept!

The attached picture is 128x64 OLED display on Proto65 rev0.1. I also want to port Conway's Life to compare the performance of 22MHz Z80 to 14.7MHz 6502. Another idea is 14.7MHz 6502 should be able to bit-bang out the 1/3-2/3 pulse width modulation in 800KHz chip rate to drive the addressable RGB LED, WS2812B. So maybe I can have more fun playing with the RGB LED array.
Bill

[BigEd]

Very nice addition! It would be good to see some Life on that.

[plasmo]

I built up a prototype board with 3 WS2812B RGB LED connected in series (Dout of LED connects to Din of next LED). The Din input of the first LED is driven with the output of bit-bang register, the same register that drives the 128x64 OLED display. The WS2812 data sheet specifies a nominal pulse width of 1/3-on, 2/3-off for a zero, and 2/3-on, 1/3-off for a one. The chip rate is nominally 800KHz. The tolerance for above spec is quite loose, so I figure I can use 6502 to bit bang out a rough approximation of the PWM codes.

6502 is running at 14.7MHz, so it is roughly 70nS per clock. Ideally each bit-loop should be 18 clocks (816KHz chip rate) where zero is represented by 6 clocks of high pulse and one is represented by 12 clocks of high pulse. I don't actually know how to write such software, but I find this little routine worked where zero is 6 clocks, one is 11 clocks and a chip is 20 clocks long. I welcome suggestion for making the timing more accurate.

In the attached picture the RGB LED are barely turned on, otherwise it will completely wash out the rest of the picture. Early on I made several coding mistakes that caused all 3 LEDs to turn full on; they were so bright, I have to close my eyes and grope around to remove the power.

Code: Select all

;color values for green, red, blue are stored in stack	
RGBLED:	
	LDX #8		;8 pulses per color
	PLA
;do green color
ColorG:	
	ASL		;most significant bit first
	STY I2C		;pulse high
	BCS G0
	STA I2C		;pulse low because bit 0 of reg A is always 0
	BVC G1
G0:
	NOP		;burn few cycles
	NOP
	STA I2C		;pulse low 
G1:
	DEX		;2 cycle
	BNE ColorG	;3 cycle
;do red color	
	LDX #8		; 8 pulses per color
	PLA
ColorR:	
	ASL		;most significant bit first
	STY I2C		;pulse high
	BCS R0
	STA I2C		;pulse low because bit 0 of reg A is always 0
	BVC R1
R0:
	NOP		;burn few cycles
	NOP
	STA I2C		;pulse low 
R1:
	DEX		;2 cycle
	BNE ColorR	;3 cycle
;do blue color	
	LDX #8		;8 pulses per color
	PLA	
ColorB:	
	ASL		;most significant bit first
	STY I2C		;pulse high
	BCS B0
	STA I2C		;pulse low because bit 0 of reg A is always 0
	BVC B1
B0:
	NOP		;burn few cycles
	NOP
	STA I2C		;pulse low 
B1:
	DEX		;2 cycle
	BNE ColorB	;3 cycle
	
	DEC $f0		;ZP variable 0xf0 defines how many LED in the chain.
	BNE RGBLED

[plasmo]

I took a close up picture of the LED and you can clearly see the 3 separate red/blue/green LEDs and the controller chip. It is quite an amazing technology and cheap--LED is about 10 cents each in quantity of 100 from eBay.
Bill

[plasmo]

BigEd wrote:

Very nice addition! It would be good to see some Life on that.

I have Conway's Life running on Proto65's 128x64 OLED display. This is a photo of Gosper glide gun reaching the edge of the screen. It takes about 39 seconds for the first glide gun to reach the edge. Similar software running on 22MHz Z80 took 48 seconds, so for this application the 14.7MHz 6502 is about 20% faster than 22MHz Z80. The 6502 software is ported from the Z80's code, but I have to work around the smaller register set and simpler instructions of 6502. I am still learning 6502 assembly so I should be able to optimize the code more. Zero page pointers are quite an interesting feature that I'm still trying to figure out how to use more effectively. I also think I have a loose pointer somewhere that is trashing my program intermittently.
Bill

[BigEd]

Very nice! You might spend any length of time at all optimising a 6502 Life - hours or years!

[plasmo]

BigEd wrote:

Very nice! You might spend any length of time at all optimising a 6502 Life - hours or years!

Gosh! lots of algorithms being kicked around. None of them suitable for a newbie trying to learn 6502 assembly! I afraid mine is just a straight implementation from the Rules of Life--scanning eight neighbors of every cell to determine the next generation value. The core routine is fairly small, around 300 bytes. I probably spent more time & code gathering data from the Life universe; forming graphic data stream, and bit banging data out to 128x64 OLED display.

Since the Life universe is quite small, 128x64, it is certainly reasonable to trade more memory & lookup tables for speed and get significant speed up. Multiprocessing and coprocessing would be very cool as well. Being a mostly hardware guy, I probably would consider a hardware state machine doing convolution over the Life universe. Yep, you are right--I could spend years optimizing it, but probably won't. Yet I'm pretty sure I'll revisit this algorithm periodically.
Bill

[BigEd]

It's fun to revisit, but yes, best not to get bogged down right away! If your screen updates are slow, that's a good disincentive - you'd quickly get diminishing returns.

[floobydust]

plasmo wrote:

floobydust wrote:

Nice to see such quick progress on your project. Regarding EhBasic, I worked on a CMOS version back in 2018 and have kept it up to date with patches from Klaus. It's smaller than the standard version (<10KB), has some hooks for exit, load and save (via my Monitor which supports Xmodem-CRC16) and has some minor performance improvements as well. It also uses less Page Zero space, which is contiguous versus fragmented.

viewtopic.php?f=5&t=5760&start=15#p76030

Great! I don't have a monitor (yet) so I can only boot straight into EhBASIC, but having an exit function to return to a monitor is highly desirable. I also have wondered whether EhBASIC 'load' & 'save' functions existed and can be modified to load/save from disk. There are so much here that I've not yet explored.
Bill

Hi Bill,

EhBasic never really implemented a standard Load or Save, but Lee (author) had made some recommendations long ago on doing so. My implementation calculates the actual Basic program start and finish (for Save), then sets up the parameters used by the Xmodem code in my Monitor and calls the Xmodem routine to finish the Save. The Load also sets up some parameters then calls the Xmodem Load routine (in the Monitor) and then calculates the end and sets the EhBasic variables after the Load is complete.

I've completed a newer version of the BIOS and Monitor (2.05, but not yet on my Github page) which might be of interest. I'm thinking you could provide an equivalent BIOS for your Proto65 board that could support most of the functions of the Monitor code. I'm also working on a version 3.0x version which supports a DS1511 RTC and a Compact Flash (in True IDE mode) interface. That will hit my Github page within a month or so... as I'm about to order the next rev of PCBs, which have some hardware changes. Note that my C02 Pocket SBC uses a NXP SCC2691 UART, which I'm guessing you're probably familiar with.

C02BIOS2b.asm

(66.28 KiB) Downloaded 133 times

C02Monitor2b.asm

(157.44 KiB) Downloaded 119 times