I have half an idea...

[barnacle]

My STM Neolithic works (will/should work, if I ever get around to smearing solder paste through the stencil and finishing the software) by faking instructions to the processor so that a series of lda #xx, sta $yyyy instructions are used to copy code - nominally the boot code but it can work to any memory location - by overriding the address and data bus using an external STM32 arm chip to control the clock and reset. Once running, the intent is to use the STM as a UART communicating by SPI with the 6502 and offloading the management of the serial data to the STM.

My Romless Neo requires that the code be transferred from a host computer after every start. Minor issues include not having indicators or a way of resetting without reloading (solvable in hardware) and the slow load, about 1k/second, constrained by the serial parts. That said, I'm really happy with it.

But I'm wondering about a more complex system, which uses am STM not only as the initial boot loader and comms but also, e.g. a keyboard controller (possibly USB) and definitely a translator for a DOS-formatted (FAT32) microSD card. The STM communicates by reading/writing a small defined area of shared memory, and effectively operates as a DMA controller.

A quarter SVGA display, mono, individual pixels in the 6502's memory space: 400x300 pixels gives a handy 48x25 characters (strictly 50 across but it's convenient to use 48) using a 7x10 font in an 8 by 12 cell. That would require 14,400 (0x3840) bytes for the screen memory and 1280 (0x500) bytes for a 128-deep font table. This would need a 20MHz dot clock; a simple approach would just divide by 8 for a 2.5MHz system clock though a faster system could arrange things at twice that speed or even, with care, a 20MHz system though I'm not chasing speed here... I need to draw some timing diagrams.

But that display could fit along with a space for the reset vector and around 256 bytes of I/O space and a further 256 bytes of DMA space in the top quarter of the 6502 memory space:

Code: Select all

0xfffa-0xffff - vectors
0xff00-0xfff9 - I/O, probably one to three 65c22
0xfe00-0xfeff - DMA transient area
0xfd40-0xfdff - control data buffer
0xf840-0xfd40 - font table
0xc000-0xf83f - video ram, first row at 0xc000, next 0xc030 etc
0x0000-0xbfff - program ram - video ram is on same chip(s)

So far so good. But here's the sneaky bit... since the 65c02 can be stopped on either clock phase as a fully static part, and the clock and other controls are under the control of the STM, and the STM also drives the address and data lines if the 6502 isn't do so, then the STM can stop the clock, read or write from the DMA and/or control data buffer, and turn the clock on again, and to the 6502 it's all just travelled in time. For a longer process, like an SD card read, you'd probably want to trigger the read and then carry on doing stuff until you get an interrupt to say it's happened. Some sort of interrupt to the STM, probably.

I think the only tricky bit is to ensure that the video clock - which will of course be reading video ram on the off-phase - carries on as normal during all the shenanigans. And I don't think it's too tricky...

Doing things this way means that I can make something working vaguely along the lines of CP/M; loading programs as and when required from an external microSD without having to fill several k with the handling code.

I feel it has possibilities...

Neil

[Yuri]

I presume the STM32 is like most other MCU's in that you can control the pins directly from software.

If so, you could get really fancy and make your STM32 do some bank switching. Maybe doubling up the font/video memory for example to free up more of the address space.

Edit:
As for video sync, I know that it's been done to death in other topics, but I like the approach the SuperNES/NES used in that you load up a bank of memory with what you want copied to the video memory, and then your MCU would get an interrupt on vblank/hblank and then DMA that over to the video memory.

[barnacle]

Hmm. A minor problem has reared its ugly head... in the SVGA section, I need to address the 800x600 as 400x300. For space reasons, I need to keep the video memory contiguous; I need 14,400 bytes. Using a 20MHz clock, divided by eight for character cells, gives a 2.5MHz tick. Using that, the default timing is achieved with 50 ticks of active line, 2.5 ticks front porch, 8 ticks of hsync, and 5.5 ticks of back porch. Which rather irritatingly adds up to 66 ticks per line, but never mind.

A little adjustment to 48 ticks active line, 4 ticks front porch, 8 ticks of hsync, and 6 ticks of back porch shifts the image a little sideways and gives a convenient line length - 0x30 - but I had envisaged a line and field counter which would only count when the line was active, and so would track the bottom bits of the line timing which would reset at 66 anyway.

But... I also need to read each line twice... which means I can't do that. At the moment it looks as if I shall have to *add* the line position to the current start of line, which has to increment by 0x30 every _second_ line. I feel the use of some adders and some preloadable counters coming on, which makes things rather more complex than I had originally hoped.

Aye well...

Neil

[barnacle]

Code: Select all

line count     0000 0001 0002 ... 002f 0030 0031 <syncs etc> 0041 (repeat every line)
line 1 addr    8000 8001 8002 ... 802f 
line 2 addr    8000 8001 8002 ... 802f
line 3 addr    8030 8031 8032 ... 805f
line 4 addr    8030 8031 8032 ... 805f
line 5 addr    8060 6061 8062 ...

So the address has to increment by 0x30 every second line, and needs the line count adding to it to give the actual desired video ram address.

Needless to say, I'd like to do this with normal logic... I suppose I could use a prom somewhere?

Neil

[gfoot]

Yes, double-scanning with a non-power-of-two stride requires being able to reset the counters at the start of each scanline - unless you do something like storing the whole row in a FIFO to replay it several times.

I've thought about this before but not come up with anything particularly simple. One option is to capture the counter values at the start of a scanline and reload them at the start of the next one if it is a duplicate. Another is to use adders to advance vertically, and another set of adders to add on the values of horizontal counters over the course of the scanline to form the address. I guess you could also have two sets of counters with a different initial value and use one set on even lines and another set on odd lines.

I haven't thought of anything particularly simple or elegant. But a side advantage of these schemes is that it's pretty much the same hardware you need to support scrolling, so maybe it is worth the investment.

[barnacle]

Kind of almost building a processor core just for the video: registers, ALU, and feedback

Neil

[gfoot]

Heh yes, though not very general purpose. Though if you are using adders, then you kind of don't need actual counters any more - you can just add 1 from pixel to pixel and subtract $2F instead of you need to repeat a scanline - so maybe that is as little simpler and also more generic.

[barnacle]

I think I still need the character counter for the line timing - seven bits of it. The ultimate end of this would be adding from registers set by the processor, so it can configure the display on the fly... not sure I want to get that far into it

[barnacle]

Here's a first thought on a line doubling system.

If repeat_line is high, the count subtracts 0x0030, otherwise it adds 0x0001. Still need to think about the logic of ensuring that repeat_line only holds for one clock every second line, but the concept is there.

About 10 chips so far: two 8-bit latches, four 8-bit buffers (or maybe just two and some resistors), and four adders.

Neil

[barnacle]

Here's another thought: it takes six four-bit adders, though, and the line counter on top of that (both it at the one above still need character counters) but it's perhaps conceptually a bit simpler if less flexible: the left hand adder multiplies the line count divided by 2, by 3; effectively by 0x30 because the lower four bits are zeroed. The four lowest bits of the count can be supplied directly since they can't affect the higher bits, but sadly the next two bits can, hence the need for two 12-bit adders (aka six 4-bit).

The big advantage is that it doesn't need synchronous counters so I can fit eight bits in a chip.
Neil

[Yuri]

The way I've generally considered to work through this is to have two sets of counters one for the horizontal and one for the vertical.

You'd then pipe in the horizontal counter into a set of address bits in the RAM, and the vertical into the other address bits, dividing the memory up.
This would leave some holes in the RAM, but it seems like it'd make the math easy.

Something like so:

Edit:
Of course reading back I see you want to keep the memory contiguous, so disregard the nut quietly laughing in the corner. He's harmless.

[barnacle]

Yeah, that was my first thought, but non-contiguous ram - 64 characters albeit on a 66 cell line would be *easy* - wastes loads of ram, and it's all in tiny chunks that are basically neither use nor ornament.

But I think a 393 for the line counter, a tiny amount of decode for the active line and sync, and a couple more 393s for the line counter, plus half a dozen adders ought to do the trick...

Unless... what if I use the extra 16 bytes on each line for the font table? I'd have room for three hundred characters... but addressing them would be less than quick. Maybe not.

Neil

[fachat]

The old Commodore PET implemented the video output with a single counter and two state bits, plus a hold register. That's pretty ingenious.

The two state bits define 4 phases, pixel out, front porch back porch and sync. Depending on phase, the counter is reset after different count values (the comparator is even optimized so that only a few bits are checked instead of all counter bits.) There is an additional row counter for chars. Depending on its value the hold register keeps the last value of a line reset, to reset for a new rasterline withinbthe same char - or is transparent in the last rasterline of a char, so it can latch in the new reset value for the next char row.

I'll have to do a writeup, it's really cool. And I need to compare to Woz' design to see who needs more logic... ( I guess the PET but what does it cost the Apple...)

[barrym95838]

Many of you are no doubt familiar with the Apple ][ video system ... Woz hacked together a non-linear hardware-optimized scheme that has left programmers scratching their heads for five decades, but he did it all with off-the-shelf TTL.

[fachat]

Yes but the PET also only used off-the-shelf TTL and still has a proper linear video address space...