Converting the 80 Column Color 8x8 NTSC Text Driver to support 16 rows of 12 bit high characters?

Kallikak

I've just been catching up on years of the Propeller forums!

I recently repaired a TRS-80 clone and have been looking at ways to exploit the expansion interface, and connecting up a Propeller is definitely a good option. I have played before using SpinStudio.

One idea I have is to improve the video (e.g. adding colour and new characters) by using the 80 Column Color 8x8 NTSC Text Driver, but I need it to be 16 rows of 64 columns, and instead of 8x8 characters I need 8x12.

The trouble is I am not very familiar with video generation. I've been reading the docs and the code of various drivers available on the parallax object exchange, and this driver looks the best for my needs seeing it already supports 64 characters per row, and 16 lines of height 12 pixels matches 24 lines of height 8 pixels.

The thing that is particularly puzzling me is how scanlines are mapped to rows inside the Text_GR.spin code.

I am hoping that all that will be needed is an appropriate font definition and some minor changes to the pixel fetching loop, and would appreciate any pointers.

Thanks,
Ken

yeti

Have a look at "Need help with video driver (TRS80)".

"TRS80 in Action" looks like using the right video mode...

Somewhere in this forum there should be a TRS80 emulator too... but I didn't find it fast enough and RL calls... :-/

Well... maybe the path modifying a monochrome driver to colour is too tricky? Use one Propeller for each colour plane?

Kallikak

Thanks.

The trs80 text driver in the first link looks interesting - no colour, but 6x12 character size and 12 rows of 64 characters. I'll have a try running the demo tonight.

Ken

Kallikak

Well I can run the code in that first link ok (for PAL anyway, the NTSC code produces no output for me), but I get the repeating line bug the author mentions in his post. It is not clear from the discussion, but it seems possible that the fixed version he mentioned is not attached to any message. :-(

I found what looks to be a final version here https://hive-project.de/content/4530 in the context of a complete TRS-80 emulator. I tried extracting just the video and vga driver code, but was also unsuccessful in getting it to run. (Indeed, even compilation was a problem.)

Frustrating, because I'm sure it just takes a little more understanding and I can get it working.

Anyway I've learned a lot over the past few days trying, and will keep at it! :-)

Ken

rosco_pc

the original thread: http://forums.parallax.com/discussion/121050/need-help-with-video-driver-trs80 is maybe helpful

potatohead

Hey all. The driver I wrote can be modified. I'm not where I can do that, but anyone who wants to has my blessing. Not that it matters. It's MIT licensed.

Hack away!

Later today, maybe over the weekend, I'll comment it and drop a few notes.

Before I do that, I have two questions:

Is having more than 8 pixels per char important?

Is the intent to just be a video display terminal?

I'm asking, because font data will need to be 8 or 16, which is byte or word sized. Say one wants 9 pixels, or 12. Two bytes will come in for display, but WAITVID will only write out the required pixels. This is wasteful, but just fine otherwise. Fonts go from 2 to 4kb.

Secondly, say one wants more than 8 vertically. Two choices there. One is to locate chars on non power of two boundaries. This takes an expensive multiply, or lookup table to do. Will slow the driver, not as many chars possible horizontally. Might be shift and add too, depending. Either will slow the driver, but by different amounts.

Or, does it make sense to do the same as for the horizontal pixels and make chars 16 lines high, but only display the required ones? Say, 9 or 12 again. That will be fast, but font size will grow again to 8kb, with some data unused.

If this is just a display terminal, great! Neither of these things is hard. Keeping to the powers of two makes character drivers sing. And an 8kb font, plus screen and color buffers leaves plenty of room for interface code.

Let me know, and I'll comment with some prototype code and notes that should be enough for someone to get there.

I'm neck deep in a startup. 3d printing related. It's a ton of fun, but has most of my time at present. It will also soon be shipping a product with a prop chip. (Not printer ....yet, but still cool.)

Kallikak

Well my needs are even more basic than a terminal - the TRS-80 has 1K of video RAM which I intend to shadow in the Propeller (by watching writes to the video addresses), and then it is simply a matter of updating screen locations as they change. The quirk of course is that the locations are organised as an array of 64 by 16 cells, each containing a character defined as 6 bits across and 12 bits down. Pullmoll's video code does the necessary bit to byte packing to handle this arrangement. Then enhancement I hope to provide to my TRS-80 (actually System-80) is improving the font (e.g. adding lower case and some special symbols) and colour - even if just whole screen foreground/background colour.

If Potatohead's driver can be modified to support the required layout, then it is the most general solution and will give the best colour support, but I'm pretty sure the driver in the TRS-80 emulator code will get me started, albeit in monochrome. But I can't yet get it to run thanks to what seem to be quirks - using C-like #define for example, and what is the @@@ operator?

Ken

potatohead

Where you gonna put the color in the TRS 80?

Kallikak

I plan to use a Z80 output port to send video control instructions to the propeller, which it will interpret and then use in its display driver. I have 2K of free ROM to add support routines for such things.

The most important use of the propeller though is enabling me to read and write an SD card - playing with the video is a secondary outcome.

Ken

potatohead

Ok.

msrobots

#define and @@@ are enhancements of the spin language, sadly not supported by the Parallax PropTool, but by two other Spin compilers named Homespun and BST.

I am not sure if OpenSpin does support them, as far as I remember OpenSpin supports #define but not @@@.

this @, @@ and @@@ thing is quite confusing, so I do my best to explain.

@variable will give you the absolute HUB address of a variable AT RUNTIME.

you can not us @variable at compile time.

DAT
myvar long 42

PUB getAddress()
RETURN @myvar

works. What does not work is

DAT
myvar long 42
myvaradr long @myvar

here comes @@ into play giving you the OFFSET of a variable from the beginning of the object containing it.

DAT
myString1 byte "hello ",0
myString2 byte "spin ",0
myString3 byte "world!",0
myStringOffsetArray long @@myString1,@@myString2,@@myString3

The above part works at compile time to build your offsetarray but you still need to add the address of the object itself to the Offset in your array AT RUNTIME.

PUB getAddress(index)
RETURN @0 + myStringOffsetArray [index]

This is where SPIN ends and the extension begins to make sense, because

DAT
myString1 byte "hello ",0
myString2 byte "spin ",0
myString3 byte "world!",0
myStringAddressArray long @@@myString1,@@@myString2,@@@myString3

will contain the real HUB address and not the offset inside of the object. AT COMPILE TIME

PUB getAddress(index)
RETURN myStringAddressArray [index]

does not need to add the object offset.

Anyways,

Mike

potatohead

So, we got read from SD, bus watchdog, 8k or so somewhat wasteful video buffer, command interpreter, probably just simple state machine.

Anything else? Seems like that stuff will fit!

Sunday. I'll comment that driver and supply some notes. Would be a doddle to mod it, but I am just not where I can do that.

Gonna think on what is needed and get some much needed, overdue family time in the snow tomorrow.

Kallikak

Anything else? Of course. :-) There'll surely be a couple of pins and a cog free for some audio. :-)

Enjoy the family time.