320x240 12-bit chunky display on an ST

[Steve]

OK, I might be taking the Michael now...

BW

You may take Michael, spin him around, return him & I would still accept this Michael.

[Badwolf]

You may now watch it in all its one frame-per-fortnight glory!



BW

[shoggoth77]

tell me how? Or point me at a manual. I didn’t know how to tell the VDI what the hardware was capable of so just let FVDI do it for me (modifying the Line A variables let me do 640x480 16 col planar, but I didn’t want that).

I was thinking NVDI. I've written some experimental drivers for it, perhaps it could be tuned a bit to work on your config.

Question is - since this isn't a Falcon, the resolution dialog will be kind of limited.

Tech questions:
- is the framebuffer memory mapped?
- what's the relation to the shifter - does this thing function like graphics cards do on the platform, i.e. in parallel with the shifter?

EDIT: "written" == steal with pride; disassembled, rewrote.

[Badwolf]

tell me how? Or point me at a manual. I didn’t know how to tell the VDI what the hardware was capable of so just let FVDI do it for me (modifying the Line A variables let me do 640x480 16 col planar, but I didn’t want that).

I was thinking NVDI. I've written some experimental drivers for it, perhaps it could be tuned a bit to work on your config.

Question is - since this isn't a Falcon, the resolution dialog will be kind of limited.

Since there's only one resolution, it doesn't really matter.

Tech questions:
- is the framebuffer memory mapped?
- what's the relation to the shifter - does this thing function like graphics cards do on the platform, i.e. in parallel with the shifter?

- Framebuffer is at C00000 to C7FFFF
- Shifter carries on doing it's thing -- only the VDI knows about the new screen so all console style output still goes to the monitor port.

I didn't demonstrate the latter in the video, but an example is when running EmuTOS, hitting CTRL-Z to open EmuCON brings it up on the other screen.

BW

[agranlund]

Wow, this amazing even at this stage of development!

Do you think it would benefit from sitting on anything faster than the ST bus?
While I do like my internal ET4000 it's not exactly a speed demon being an ISA card on an 8Mhz bus

Basically, what immediately popped into my head was something along the lines of: toss my existing ET4000 and hook some modified version of your invention up to the IDE port of the TF536 (with special firmware)
I'm not using the TF536 IDE port anyway and my ST is already modified for internal graphics card so it could slot in quite nicely.

[sporniket]

Cool experiment

[Elethiomel]

This is simply amazing. Great work!

[Elethiomel]

Basically, what immediately popped into my head was something along the lines of: toss my existing ET4000 and hook some modified version of your invention up to the IDE port of the TF536 (with special firmware)
I'm not using the TF536 IDE port anyway and my ST is already modified for internal graphics card so it could slot in quite nicely.

That would be great. There's probably enough there to do a 15 bit bus at 50MHz.

[Badwolf]

Do you think it would benefit from sitting on anything faster than the ST bus?
While I do like my internal ET4000 it's not exactly a speed demon being an ISA card on an 8Mhz bus

There's nothing to stop me trying this at 16MHz, I suppose.

The DTACK signal is very basic at the moment. There are four states in the state machine and states 2 and 4 are the interface from SRAM to the ST and vice versa. Upper on state 2, lower on state 4. The DTACK therefore just counts states since the chip select came in and asserts DTACK after 5 of them!

5x20ns would be 100ns, which is still under a 16MHz 125ns bus cycle, so it sounds like it might see a two-fold benefit.

Basically, what immediately popped into my head was something along the lines of: toss my existing ET4000 and hook some modified version of your invention up to the IDE port of the TF536 (with special firmware)
I'm not using the TF536 IDE port anyway and my ST is already modified for internal graphics card so it could slot in quite nicely.

How many lines do you have control over on the IDE port? If there are 16 data bits on there and seven ground, that's only 17 pins left. Not enough for the addressing.

Multiplexing address and data on the data lines going into two 16 bit input flipflops? That would seem doable.

Reading the data back out might be harder to co-ordinate, though.

If only i could get my own multiplexer working properly.

BW