I'm just remembering... back in 2016, there was a forum thread about something like two 6502 chips sharing a bus, where that sort of topic had showed up.

My suggestion for clock generation and R/W# had looked like this:
//It was just a theoretical idea. Not tested with real hardware. Might still need some tweaking etc.



;---

Hmm.
But before we start with writing the specifications for a multiprocessor 6502 gaming system,
I think we should wait until and3rson has decided what he actually _wants_ to build...

Thank you for your inputs everyone!

Sorry for the delay - I've been spiraling down the rabbit hole with SD card (SPI mode) and FAT16, and it took me some effort: whenever I'm facing some challenge, I tend to forget about everything in the world and try and solve it.

Updates so far

I was eventually able to teach my SBC how to read FAT16 from an SD card. This was great! I'm sticking to 1 sector per cluster for now (I wanted to avoid extra arithmetic on sector calculations), I implemented routines for parsing MBR & bootsector, and for reading root directory. So now my uREPL (fancy abbreviation for a tiny REPL monitor) can load & run programs from my FAT-16 formatted micro SD. However I also learned that re-flashing my ZIF-socketed ROM is actually faster than sticking a micro SD back and forth. But hey - my SBC now officially has external (read-only) disk support!

I also "invented" a neat way to print strings defined right after the `jsr` instruction by altering return pointer (PC). I wanted to share this as a great achievement, but eventually found out it's been used all over the place already, and it's even been described in the source code section here: http://6502.org/source/io/primm.htm
It saves a lot of time and all strings are nicely stored directly in the code, and it also saves some ROM bytes since I don't need to load 16-bit string address into registers/zeropage before calling "print". "Yeah, mr. Von Neumann! Science!"

As for my PCB, I've ordered a bunch of Aries low-profile sockets (28-526-10) from Mouser, they are noticeably smaller than typical ZIF sockets, and so I was able to squeeze a mini-DIN-6 (PS/2) connector to my board, as well as some more headers, plus a socket for micro SD card adapter. The board looks much cleaner and less crammed now!

I also feel like I'm learning to respect CPU flags, and they are starting to respect me. I still cannot call them close friends, but there were moments when they were set to the right value just in the right time, and it feels wonderful to be able to eliminate additional instructions before branching.

Finally, I've been thinking about using some illegal instructions to achieve memory banking with some minor glue logic.
Jeff - I found your article about illegal NOPs in KimKlone, specifically LDD zeropage. It was very helpful!
I didn't plan the circuit yet, but the idea is to use one of NOP opcodes that discard retrieved value in order to trigger a 8-bit latch during SYNC=high, and read the operand in the next cycle. This will allow to have a 3-cycle memory bank switch in a single instruction without altering any registers, and support up to 256 banks! Well, the actual usefulness of this is rather questionable, but isn't it fun?

And now, back to the video

Michael - thanks for sharing: despite me being against using FPGA magic in my SBC, I'm still considering starting with something modern to get a grip on the video. I've had an ATtiny45 lying around, and with some AVR assembly I was able to get this "beauty" rendered (4 vertical black/white bars):

(You can see me screwing up with cycles in the beginning, as well as a jag in the middle - I'm drawing 156 lines twice, and I'm off by few cycles when drawing bottom half of the field.)

Also I'm puzzled why didn't my EasyCAP detect the image when I fed it through a voltage divider (to get 1V peak instead of 5V), but worked fine when I fed 5V directly:


Neil - that's cool, I totally forgot about VGA!

Dieter,
> elm-chan Laser projector, or dot flippers"
Now THIS is art! Yeah, composite video turned out to be really easy to do. The bigger problem for me is to nicely fit it into my system so that it can actually draw something useful!
I've recently stumbled upon Bill Herd's video on direct digital synthesis. Digital-to-analog conversion surely is an interesting topic!
> looks like Mouser doesn't have IDT dual port RAMs anymore
Yeah, dual-port RAM would make it so easy to share framebuffer between CPU & video subsystem. I only recently learned about it, turns out it's already discontinued.
> I think we should wait until and3rson has decided what he actually _wants_ to build...
This is a good question actually, the problem is - I don't know what I'm building! The only thing I know is it must all fit on a 100cm2 to be cheap! But seriously - I'm still evaluating all the possibilities, since I'll need to choose what's realistic but not too boring!

Gordon - I've also went an AVR path for now as an excercise. Also, personally for me composite is most convenient, since I own few capture devices & TVs that support it. In fact, the two TVs I own (both Mi TV, made circa 2020) actually has 3*RCA composite input, but no VGA/SCART. What a weird piece of hardware!

Michael - that's a nice little TV, and the price is awesome! I'd totally love to own one. But I guess I'll need to get a separate place to hold all my electronics first (I've been thinking about this for some time now), since this TV will be the last thing I buy before my wife throws me out of the house! (Together with my 8 commodores, few Atari devices, TI/99, a bunch of Speccies, a dozen of mechanical keyboards, and few boxes of wires/perfboards/resistors/MCUs and all sorts of stuff.)

Jeff - thanks for the link, I don't know much about 6509, this will be an interesting read!

EDIT: Okay, the composite signal is actually noticably better when viewed on my real TV! I've also fixed few timing issues and the edges are kinda smooth now. The top slope is gone when connecting to TV, but EasyCAP still shows it.


As always, keeping all my code updated: https://github.com/and3rson/65ad02/blob ... c/main.asm

/Andrew

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

I've decided to go two paths for now.

First, I've ordered an old TMS9928.
Pros:
- No DMA required, so I can use my '138 to drive it. I'm going for text mode only, so the bandwidth is not a problem.
- It has its own VRAM, so more free CPU memory space for my code!
Cons:
- According to my own rules, it is in fact "cheating". However, it is still going to be helpful to get a reliable video subsystem with least effort before starting something more complex.
- It's NMOS and it's doing video stuff, so I anticipate it getting hot & dead pretty fast.

Second, I've ordered an old MC6845.
Pros:
- More freedom for implementing custom rendering.
- Not a cheating!
Cons:
- More work for implementing custom rendering! This will be a real challenge.
- Some sort of DMA will be required.

I'll see how well they will align with my "free" time. If my brain won't be able to handle the complexities of DMA & bus sharing in a reasonable time, I'll just stick to 9928. Getting something "imperfect" to work is better than chasing the "perfect" solution forever anyway!

P. S. I feel like I've seen some sort of hate towards Texas Instruments. Are there any specific reasons for this? (Besides the ridiculous prices on their scientific calculators.)

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

So it turns out I really don't need 48K of RAM! I'm mostly using my SBC for various software stuff as well as playing SID tunes, so 32K RAM would be perfectly fine.

I spent some time redesigning my address decoder, and it turns out that by just adding 1 extra NAND gate I can split my ROM into two segments - low (16K, $8000-$BFFF) and high (8K, $E000-$FFFF).
Main reason why I'm not placing them in a continuous segment (e. g. $A000-$FFFF) is because I want to keep my I/O at $Dxxx in order to be compatible with SID tunes (since SID has to be at $D4xx).
I can then use high 8K for reset/interrupt vectors an kernel-ish code, an lower 16K for actual "programs" (or even bank lower 16K).

I ended up requiring 7 NANDs on my first attempt, because I calculated equations for low ROM & high ROM separately as such:


However, after carefully re-thinking what bits need to be activated, I've actually managed to get the number of gates down to 4:

NANDs are so magic!



So my new memory map is:

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

You could probably run BBC Basic in that configuration - squeeze enough Acorn MOS into that high 8K ROM and BBC Basic at $8000-$BFFF... My own OS is about 10KB but it contains a lot more stuff for me (and a bit less than the Acorn MOS, so trade-offs each way) I also found it easy to run both EhBASIC and CMB2 Basic in that configuration too.

But the 32K comment is interesting - when the Beeb came out in '81 a big whinge was that it only had 32K.. It didn't stop Elite running though....

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Andrew, may I ask if there is an upper CPU clock limit when using an SID IC?

Sorry for being gone - I've had some intense stuff on my back...



Good question! I've managed to run SID on frequencies >1 MHz, but it just didn't sound right - low frequencies were inaudible and high frequencies felt too pitched. I've ditched the idea of incorporating SID for now since it requires clock stretching (I saw some articles on this forum, including some nice solutions from Jeff using a JK flip-flop).

My idea was to run SID on constant 1 MHz and underclock 65c02 when it attempts to access SID by putting it on SID's clock. This requires some trickery though, since in some edge cases the 65c02 (say, running @ 8 MHz) should wait for up to 8 whole cycles until SID's Ф2 goes low. I'm still figuring it out, will post an update if I find a nice solution!

I also have SwinSID, I think it should run at any frequency since it has its own 16MHz clock. But that offends my inner purist!

Also, I've decided that for now I'm fine with character LCD. Somehow I don't feel that much affection towards real video for now. I want to spend more time practicing my 6502 assembly. So I found a big-ass 4004 LCD (it actually seems to run 2 HD44780-compatible chips, since it has 2 EN lines, similarly to 128x64 LCD).

I totally love the look & form-factor of Tandy Model 100 & Atari Portfolio: the combination of character LCD & keyboard in one case is so cool.

So I decided to make a new build, inspired by Tandy Model 100. I wanted to squeeze in a mechanical keyboard as well (I'm very much into them, I've built around 30 so far), but I was afraid it will end up being too bulky, so I kept a PS/2 port to use an external keyboard. Still, a built-in low-profile mech keyb with Kailh Choc switches is something I'll try out in future!

I've also made a custom footprint for it to properly align the 4004 LCD with my main board.

Finally, I've added ACIA + MAX232 and a header for external MicroSD SPI adapter.

I've increased my PCB to ~19cm*10cm and here's what I've ended up with. I love how it looks!

(The only downside is that my precious DIP chips are no longer visible!)



PCB - DipTrace rocks as usual (though ZIF socket needs minor tinkering with trace clearance):



Sandwiched screen:



I'm way over 100cm² now, but hey - L A R G E LCD!

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

That looks very nice indeed!

For sound, if you want musicality as such rather than specific compatibility, might be worth considering Yamaha's OPL2 which is a DIP with, I think, a reasonable bus interface.
http://www.vgmpf.com/Wiki/index.php?title=YM3812

I think the new PCB looks nice, too. What are the dimensions of that LCD display? If you eventually publish the Gerbers, could the can oscillator footprint be modified to support either 'short' or 'long' versions?

About the SID chip... I wonder if the article Hardware SID Player by Dr. Nicholas FitzRoy-Dale may be of interest? BTW, this article is where I first learned about a simple microcontroller "blind interface" to 6502, 1802, Z80, etc. about ten years ago.

Regards...

Thanks!

Yamaha is a cool idea! I never worked with them, but I love how they sound. SID is still closer to my soul, but I've always wanted to experiment with OPL. I think I'll get some and see where it goes.



Thanks for sharing! However it still looks like they run it on 1 MHz... Which is ideal for SID, but I want my CPU at 4 or even 8. Thus I'll need to find a way to put 6502 on slower SID's clock (Ф2 div when it attempts to address the SID. This needs some synchronization magic though, since in some cases I'll need to delay SID/EN if Ф2-div-8 (SID clock) happens to be in high phase when 6502 wants to address it.

EDIT: Forgot to mention: the display is a big boy, measuring 190mm*54mm (~7.48"*2.13"). Here's the blueprint for it (I hope it's correct):



I also keep my gerbers & schematics posted here: https://github.com/and3rson/65ad02/tree/main/diptrace
Also, here's the footprint for Kicad that I made for it: https://github.com/and3rson/65ad02/blob ... .kicad_mod

There's also some 3D models I've found around, including the one for the 4004 LCD, too.

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Another way might be to have a "slow" data bus - essentially an 8-bit port and a few control lines for r/w and chip select. The BBC Micro did it that was for it's sound chip.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Oh, interesting! So is it more of a bit-banging approach, if I understand correctly? (I.e. treating chip select, r/w, data, & 5 address lines as registers)

The problem is that SID tunes (basically, all tunes from HVSC collection) are just native 6502 programs with subroutines that need to be called by main program every frame (50/60 Hz), so I don't have any control over how they access SID: they're all just machine code that directly mutates SID registers, so they need 6502 to have SID directly memory-mapped in order to play.

Thus I'm afraid that clock stretching (or rather stretching + syncing) is the only option.

Here are two possible siturations:



Ф2 is 8 MHz clock, ФSID is Ф2 divided by 8.
Ф_CPU is 6502's Ф2 input, it can be either Ф2 (normal 8 MHz operation) or ФSID (synchronized with SID's 1 MHz clock).

Here's some details on those:

• In first situation, SID/EN can be asserted instantly when SID address becomes valid, since ФSID is low, so we can just kick 6502 from Ф2 onto ФSID (1 MHz). When ФSID goes low, we've finished reading/writing, so we can put 6502 back * onto Ф2 (8 MHz).
• In second situation, address is valid, but ФSID is still high, so we must wait for it to go low (to prevent accidental writes mid-high-phase) and only then assert SID/EN. Then the process continues as in the previous flow.

I *think* I can consider this process as a state machine and add some flip-flops & NANDs to do all of the transitions in an over-engineered fashion (since my knowledge of discrete logic is currently limited by simple logic gates, RS flip-flops, and basic stuff like '138/'273), so I'm pretty sure Jeff will then come and tell me that it all can be done with a single JK flip-flop

I'll give it a try anyway!

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD

Well, more byte banging ...



Oh - I never knew that, but then I was a BBC Micro fan and not a C64 fan, so ...

Hope you get it sorted.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

this is phenomenal.
Way to Go

Thank you!

Sorry - been totally overloaded with work for the past few weeks, dropping by for a quick update & some bragging.

V15 board assembly

While waiting for 4004 LCD from AliExpress, I was lucky to find a used one at local bulletin board for ~5 USD. So now I had everything I needed for a final assembly! Here's what it turned out like.

I've ordered a new board from my local vendor. This one cost me ~30 USD and took 3 days to make, and as I mentioned - it's a 15-minute drive from my home, so I'm really lucky. The blue silk screen looks so much nicer than the previous green one:

I'm a sucker for those pristine looks of a fresh PCB with basic sockets soldered:

Soldering finished, taking one last look on those beautiful chips before I hide them beneath the LCD:

All done, trying to pose the board with some better lighting (I suck at taking photos):


And - done. BIG SCREEN!


As you may have noticed - I eventually ditched the Aries low-profile ZIF socket in favor of a standard bulky ZIF. Main reason - Aries has a really nice hi-tech look and is extra-small, which is great for PCBs with limited space. However it's painfully inconvenient to use, especially when constantly re-flashing my EPROM, and also makes it much easier to misplace a chip and bend some legs. Standard ZIF, on the other hand, is much more convenient: I simply throw the chip on it, and it always lands perfectly.

Those damn Chinese "standards"

I had to use taller standoffs (~0.8") since the pinout of LCD I have doesn't match the one I'm still waiting for. So I had to bend the legs as such:



This stole around 0.4" of space, but hey - I'm good with it for now. I still think I can go down to 0.4" with a properly matching LCD footprint.

Another pain was LCD pins: some 4004 LCDs have 18 pins, and some have 16 (backlight power is on the opposite side of the LCD PCB, as seen in my photos above).
What's even worse - some Chinese LCDs have pins 1-8 correspond to D0..D7, and some - to D7..D0. This is absolutely terrible.
Luckily, all other pins match. So here's where 4-bit LCD interface shines: I can simply connect pins 1-4 to pins 8-5! Since I had only half of data lines connected (obviously, the wrong half), all I had to do was to add some jumpers to mitigate this:



This way the socket will handle any ordering, so I can buy all the LCDs (unless the manufacturers mess things up even more!)

"Life is too short to write in Assembly"
Don't get me wrong, I've always loved assembly. However sometimes I really want to do some quick prototyping with good old C. Some would argue that life, in fact, is too short to write even in C!
I had to tinker for few days in order to make a proper config file for CA65 & CL65, and most importantly - to make kernel's routines properly callable from C programs. Took me a while to realize that CC65 actually uses software stack.
I ended up reusing a single CC65 config file for both the ROM and the C programs:

Additionally, I wanted my kernel (which I called "Kore", like another popular kernel with a "typo" in its name) to own the zeropage, including 26 bytes that CC65 needs for software stack, pointers, etc.

Eventually I've managed to glue everything together, so now I can write programs in C, compile them with CL65 (which automatically includes all the "magic" `libsrc` functions for stack/comparison/arithmetics, etc), copy to my FAT16-formatted SD Card, stick it into my SBC, and run everything! All my code is on GitHub as always: `rom` folder contains the kernel ("Kore") and the "OS" ("MicroREPL"), and `sdcard` code contains C programs.
Also, now I don't need to reboot my SBC after the program terminates, because it's using its own zeropage section, plus ~32 KB of RAM that's not used by the kernel (minus 160 bytes of 4004 LCD "video memory", several hundred bytes for FAT cache, etc), so the application can simply return back to my MicroREPL "OS" and I can then run more applications. This gives me some "DOS" look-and-feel, where applications cooperate with OS, instead of yeeting the latter out of existence and requiring a reboot to get back into the OS.

Of course, I couldn't resist writing a simple Snake game to celebrate this:

https://youtu.be/boeysL1Isg4

Great success!

EDIT: The major downside of writing in C for 6502 is that programs end up being huge: the 200-line C code of my (terribly unoptimized) Snake game compiles into a 3.5 (!) KB binary. Of course, most of it is juggling with software stack. Also, I could probably reduce it a bit by moving all helper routines (pushax, etc) into kernel and link them during C program compilation.
So yeah, CL65 is awesome, but it's nowhere near as good as a human writing in actual 6502 assembly. Looks like C only shines when it has plenty of large CPU registers to deal with.

I've also been looking at Forth recently. It looks like the best candidate for writing both high-level and size-friendly code for 6502, since it doesn't need many registers and heavily relies on stack. I might give it a try in future.

Thanks for reading!

/Andrew

_________________
/Andrew

deck65 - 6502 slab with screen and keyboard | ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) | leo80 - simple Z80 SBC
nice65 - 6502 assembly linter | My parts, footprints & 3D models for KiCad/FreeCAD