I/O mapped to F0xx

[epaell]

And/or Mac

BTW, I just tried some crystal swapping. I had a 2 MHz crystal in my version and that worked, upped to 4 MHz and that also worked fine but I couldn't get a peep out when running at 8 MHz. I also tried 7.32728 MHz and 4.9152 MHz neither of those worked. If anything, I would've suspected the 68B50 as being the limiting factor as I don't think it is rated to go over 2 MHz (I could be wrong) even though it clearly still seems to work at 4 MHz. Did you say you had these exact same chips all running at 8 MHz (including the 68B50?). And the SRAM was the only difference?

[Michael]

Any plans for porting this to Linux?

Certainly.

I'm trying to keep the number of versions of the runtime that I need to support to a minimum. Currently I have:
- Windows (.NET Framework & Windows Forms) written in C# for the development runtime
- RP2040 MCUs (Portable Runtime : written in Hopper and machine translated to C for Arduino IDE)
- 6502 (Minimal Runtime hand coded in Hopper 6502 Assembly)
- a Hopper compiler for Z80 (written in Hopper)

I have an early project to port the .NET Framework (& Windows Forms) version to .NET Core (using Terminal.Gui). That will give us a single development runtime (written in C#) that will run on all the important platforms (including macOS and Linux) while not increasing the number of runtimes to support (it will replace the current Windows runtime).
However, this project is currently on the back-burner while I wait for the Terminal.Gui guys to make a few key improvements (like better mouse event handling and serial port support, for example).

The vast majority of the platform is written in Hopper for portability (the entire Hopper compiler toolchain, the 6502 Assembly toolchain and the IDE which includes the Editor, the Debugger as well as the Monitor that communicates with devices over serial). The platform is currently made up of ~160,000 line of Hopper code, ~20,000 lines of 6502 assembly and under 12,000 lines of C#:
https://github.com/sillycowvalley/Hopper
https://www.youtube.com/@biggertigger

[epaell]

Nice - it'll be great to see. Perhaps I can try it in a Windows VM that I have.

BTW, I was thinking about the high-speed issue ... I wonder if it is to do with having the bus? It's another difference between a fairly small and compact SBC version and the MECB version. Maybe at >4 MHz there are some timing issues happening on the bus?

[Michael]

And/or Mac

BTW, I just tried some crystal swapping. I had a 2 MHz crystal in my version and that worked, upped to 4 MHz and that also worked fine but I couldn't get a peep out when running at 8 MHz. I also tried 7.32728 MHz and 4.9152 MHz neither of those worked. If anything, I would've suspected the 68B50 as being the limiting factor as I don't think it is rated to go over 2 MHz (I could be wrong) even though it clearly still seems to work at 4 MHz. Did you say you had these exact same chips all running at 8 MHz (including the 68B50?). And the SRAM was the only difference?

Correct. The SRAM is the only major chip difference (and it looks like a fast chip compared to the 6C1008 and 62256 that I use on the other board).
I use the MC6850P and it runs just fine at 8MHz on my own SBC:
https://github.com/sillycowvalley/Hoppe ... 2SBC/rev12

Thanks a lot for trying other oscillator speeds. Still a mystery ..

[Michael]

I was thinking about the high-speed issue ... I wonder if it is to do with having the bus? It's another difference between a fairly small and compact SBC version and the MECB version. Maybe at >4 MHz there are some timing issues happening on the bus?

I've run at 8MHz on a breadboard with a nest of wires. (probably not very reliably though)
This just doesn't run at all. However, my evidence is that I cannot connect via serial so my lack of hardware handshake could be the culprit (although, I use the same protocol on my SBC at 8Mhz).
I just finished my driver for the PIA. I've write a "hello world" that blinks the LED (rather than the entire Hopper VM) and see what happens at 8MHx (perhaps some of it is working).

[Michael]

I wrote a simple LED blinker on PA0. Works fine with a 4 MHz can oscillator. Dead duck with 8MHz.

Program uses only the CPU, the EEPROM and the PIA and that was my clue (since my SBC uses the WD 65C22)

The Motorola MC6821 PIA is typically rated for operation up to 1 MHz, with some configurations potentially supporting up to 2 MHz.

The 6840 PTM can typically handle clock frequencies up to around 2 MHz. Some versions might support higher frequencies, but 2 MHz is a common conservative limit.

Code: Select all

; /Source/Projects/6502SBC/blinknoram.asm:13
; ####  Blink.Hopper()  ####                                                    0x0000

C000  D8        CLD                 
C001  A2 FF     LDX #$FF            
C003  9A        TXS                 
C004  78        SEI                 
C005  A9 00     LDA #0              
C007  8D 12 F0  STA $F012           
C00A  A9 FF     LDA #$FF            
C00C  8D 10 F0  STA $F010           
C00F  A9 00     LDA #0              
C011  8D 13 F0  STA $F013           
C014  A9 FF     LDA #$FF            
C016  8D 11 F0  STA $F011           
C019  A0 00     LDY #0              
C01B  A5 04     LDA $04             
C01D  8D 12 F0  STA $F012           
C020  A9 00     LDA #0              
C022  8D 10 F0  STA $F010           
C025  A2 00     LDX #0              
C027  A0 00     LDY #0              
C029  88        DEY                 
C02A  D0 FD     BNE $C029 (-3)      
C02C  CA        DEX                 
C02D  D0 F8     BNE $C027 (-8)      
C02F  A5 04     LDA $04             
C031  8D 12 F0  STA $F012           
C034  A9 01     LDA #1              
C036  8D 10 F0  STA $F010           
C039  A2 00     LDX #0              
C03B  A0 00     LDY #0              
C03D  88        DEY                 
C03E  D0 FD     BNE $C03D (-3)      
C040  CA        DEX                 
C041  F0 D8     BEQ $C01B (-40)     
C043  80 F6     BRA $C03B (-10)     

; /Source/Projects/6502SBC/blinknoram.asm:9
; ####  Blink.NMI()  ####                                                       0x0001

C045  40        RTI                 

0xFFFA 0xC045 // NMI vector
0xFFFC 0xC000 // Reset vector
0xFFFE 0x0000 // IRQ vector

[Michael]

This is a good read on overclocking the Motorola chips, propogation delays (glue logic is a non-issue) and memory speed limits:
https://digicoolthings.com/minimalist-e ... 809-speed/

4Mhz appears to be a good safe upperbound for now.

[Editor]

Still failing to increase the 6502 speed from 4MHz to 8MHz. Maybe it is running but the serial communication is failing since I don't use hardware control (but I don't have an issue with the same chips on my SBC - only big difference is the SRAM chip but it appears to be quite fast)?
What's the fastest others have run this board at? Which components are the weakest link, speedwise? The EEPROM?

Running super reliably at 4MHz though.

I believe the primary speed limitation is the 150ns access time of the 28C256 EEPROM. The SRAM is very fast, so that won't be an issue.

At 8MHz, the clock cycle time would be only 125ns!

A few of thoughts on this...

1. The SST39SF040 FLASH ROM's, that I use on the 1MB ROM Expansion Card (and upcoming 6309 PLCC Card), are a much faster 70ns access time.

2. The default PLD Bus Control logic for the 6502 CPU Card gates the Chip Selects (more specifically, the MREQ), with the Clock signal, to ensure a clean Valid Address etc. on. the 6502. This means that only half a clock cycle for memory access (as is pretty normal for 6502 system design). However, it may also be worth trying the removal of the clock gating, specifically for the ROM Chip Select (I might be concerned about doing this for RAM CS, in case of invalid writes!). Doing this should extend the read cycle for the ROM somewhat.

3. Related to the above, it is interesting to note that the 6809's quadrature clock (which provides Address Valid at the earlier rising edge of the Q clock), means that you have 3/4 of a clock cycle for memory access (the Q and E clocks are OR gated for Address Valid range).

[epaell]

I just tested thought (1) above i.e. 8 MHz 6502 with the ROM card and that didn't work (4 MHz worked) - so I don't think it is the ROM. It'd be interesting to try a ROM write program with a bit of test code to try the CPU card in isolation i.e. have a simple program in ROM that perhaps cycles through memory (just to exercise the processor) and at the end write "OK" or something like that at the beginning of the ROM so that it can be checked offline. That should test whether or not the CPU is actually running software and would isolate the limitation to the I/O card if it works.

[Editor]

I just tested thought (1) above i.e. 8 MHz 6502 with the ROM card and that didn't work (4 MHz worked) - so I don't think it is the ROM.

Note that with the current PLD gated clock logic, althought the clock cycle is 125ns (at 8MHz), the half cycle time (Clock high) is therefore only ~62.5ns. And, allowing for propogation delays, the memory Chip Select times are even shorter!

i.e. 150ns ROM's definately won't cut it, and even the 70ns faster SST ROMs will be perhaps (theoreticallly), too slow.

Reading the SST ROM datasheet, 'Tce' (Chip Enable Access Time), is quoted as Max 70ns for the 70ns device.
So, this potentially has a maximum Valid Data Available time which is perhaps 10ns beyond our (current) Chip Select pulse width.
I note also that 55ns Access Time SST39SF040 devices are also available! 55ns would be good, and would be within the, perhaps ~60ns or less, read access timing constraint.

At least with a 70ns Access Speed ROM, you really need to test these with my thought (2) also in play.
i.e. Potentially obtaining a longer read cycle by relaxing the Clock "high" requirement of the ROM Chip Select assertion for read access.