I like your tropical background. From a thumbnail, it is very easy to find your video among other electronics videos.
I really like the minimalism of your design. I hoped to obtain similar functionality with boards of around 24-28 square inches with chip stacking. Maybe. It is very impressive to obtain such functionality in approximately 15 square inches and no chip stacking.
Your eight indicator lights are also highly appreciated. In
Morse Code - The Debug Protocol Of Champions, I noted that multiple bits of state greatly aid development. I was highly unsurprised that for more than a decade, GARTHWILSON has been effortlessly obtaining approximately five bits of state from the tone and duration of a piezo buzzer. You are similarly obtaining approximately five bits of state from unused latch bits. This could extended with piezo, Morse or both.
Placement of video RAM is moot. Apple's technique was to place it in low memory because it works equally well with 16KB RAM or 48KB RAM. Whereas, Acorn's technique was to reserve a highly dynamic 1-20KB at end of RAM. If you seek Apple or Acorn ABI compatibility then text display at $0800-$0FFF may be an advantage for both systems. Specifically, you can load a binary at $1900 or $2000 and the range between display and program may be buffers or heap. Video at a fixed location in low RAM is especially desirable if you want upward compatibility with 48KB, 56KB, 60KB or 64KB RAM. Contrariwise, stack at one end and video at other end allows the largest contiguous range for applications. However, if legacy binaries are loaded at fixed address, end of user RAM will be a little less than necessary. If you don't want compatibility with legacy binaries or you are prepared to port specific cases then video in high memory is preferable. Either way, Commodore compatibility in $0200-$03FF is possible and the unused region (from $0200/$0400 to $07FF/$1FFF) may be buffers or heap. Likewise, placement of your video RAM doesn't affect the level of Commander X16 compatibility. Placement of video RAM at end of memory may aid higher resolution. However, even in this case, video at $1000-$1FFF may be preferable if binaries load at $2000.
You've got four unused address lines on your video character ROM. I have suggestions for these address lines, in the same manner that I
suggested uses for four unused ROM address lines in
DarkestSoul1992's opcode/operand re-write design.
Firstly, you only output seven bits from RAM to character ROM. With no additional components, it is possible to output 256 symbols. I strongly recommend $40-$7F for Roman script, $80-$BF for Greek script and $C0-$FF for Cyrillic script. At the very least, the top bit can be used for reverse video, as I
previously suggested for
plasmo's VGA6448. Alternatively, the top bit may be used for underline.
Secondly, one unused latch output may be used to select an alternative font. This could be used for graphics. I prefer one nybble for Walsh function in horizontal axis XOR with one nybble for Walsh function in vertical axis. However, that works best when foreground/background can be set independently. A more suitable scheme might be eight triangles which meet in the middle. This could create an effect similar to SpaceBall's
Nine Finger Demo on Commodore Amiga. While tiles $00-$0F could be allocated to 2*2 blocks and allow 102*60 pixel bitmap display, 3*3 blocks can be assigned such that the middle square is the aggregate of the other squares. This would allow 153*90 pixel display with minor restriction. Other allocations are also possible.
Thirdly, your video counters have one unused output and this performs a scan doubling function. This stretches 8*8 pixel font to 8*16. With no additional components, it is possible to have a true 8*16 font face.
Fourthly, it is possible shuffle all of the counter outputs and connect the bottom bit of counter output to the character ROM. This allows the 8 bit character ROM to generate 16*16 font. I really don't care if you use this functionality.
I designed an EEPROM programmer specifically so that it could program two ROMs in parallel. I'm just glad that I don't have buy or program pairs of scarce ROMs to obtain similar functionality. This only became apparent to me by studying your design. So, thank you.
By default, converting your existing design to 16*16 would reduce text columns by a factor of two. However, this may be an opportunity to double the clock speed and double the processing power. Admittedly, this may also double energy consumption and this may be highly undesirable for such a small, portable design. Although, it would double the quality of the font horizontally and vertically without additional components, requiring more system RAM or affecting the text output of any existing software.
Fifthly and sixthly, 800*600 VGA (or more) is possible. A judicious re-arrangement may further increase text quality without significantly altering RAM requirements. Specifically, 16*32 or a compacted 32*32 character font may be possible with zero extra components.
I really like your mechanism for muting junk video output. After
outlining an upwardly compatible audio/video system which shares counter chips, it became apparent to me that uninitialized SRAM serialized to speakers requires a mute function more urgently than your video circuit. This isn't a problem during normal operation but it becomes *very* important if a system doesn't start properly. I am particularly impressed that you covered this case in a minimal design - and in a less significant context.
Your design is already in the category of "I wish I designed that" and is only nudged out of my
top three due to software support. If your software support matches or exceeds Eris then it would be my favorite computer design, so far.
Login
Register
FAQ
Search
I'm curious how you managed to to switch ROM types with just one jumper; aren't their pinouts pretty different?