Uzebox 128+

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
D3thAdd3r
Posts: 2213
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Uzebox 128+

Post by D3thAdd3r » Sat Apr 02, 2016 8:53 am

So I talked about this on the forums a couple times and I am quite serious about finishing it. I need a thread to keep motivation and make it real in my head, it seems pretty weird sitting by myself doing this otherwise. I pop out of a finished product every now and then and this must be one of them! Couldn't resist, you can tell I am ludicrous about the "retro computer in a keyboard" idea since I can only fit half of them in 1 picture :? Also an interesting note, Jubatian was good enough to track down the Videoton TV-Home Computer 64k, which is a Hungarian computer(so an exotic to me), and also the Enterprise 128 which I could never find but apparently they are findable in Hungary. They have built in joysticks which is unique and I might post some closer pictures of all this stuff later(when I figure out how to make hosted pictures work right). The machines mentioned are pictured directly above the Uzebox 128s:
1.jpg
1.jpg (103.63 KiB) Viewed 2362 times
So this is probably not a real hard concept to understand, the 128+ is for SPI expansion ram(+4), and the goal is to squeeze a full size Uzebox PCB in places it shouldn't fit...don't get cute with that. I'll repeat the non-amazing story I said before. I found this dusty keyboard one day, I find lots of old garbage keyboards and random crazy machines when we upgrade fiber optic/network switches/satellite/etc; but this was so agreeable to my design tastes that I immediately thought it was the perfect keyboard(well no timers and macros so not for FPS gaming :P ). It actually served it's life as text entry for an old analog video system, the kind of thing that overlays guide information about the channels, disused for who knows how long. Well it was cool I thought, so I took it apart like I do everything, and that's the story. The keyboard is not necessarily as vintage as the IBM Model M, but to be honest and I find it to look and function significantly better without all the spring noise. It is a Keytronic LT DESIGNER.
6.jpg
6.jpg (68 KiB) Viewed 2352 times
It is a very tight squeeze but I decided on no modification of the Uzebox PCB. It might be easier with some all SMT Uzebox PCB but then I guess it wouldn't be as interesting to me. Very slight modification of an unused part of the keyboard PCB needs to be done but that is the easy part. I try to do my best craftsmanship, and the tools are simply sticker templates, a Dremel, and a hobby file set. Seems dumb maybe, but I think the whole niche of why it's cool to me is because it's handmade and I will probably do each one a little different design. It's basically cut a little, test fit, shave a little, repeat since I don't want it to look like a little kid made it.
5.jpg
5.jpg (75.12 KiB) Viewed 2347 times
The first one, still in pieces, I went a little overboard and spent way too much time on it. It includes lighted dedicated toggle switch to cut +12v from the PCB(so no unplugging to turn off), and large buttons to tie to the PCBs power and reset. The second version I opted for smaller buttons on the side. The bigger thing that took some real time is the lighted "stained glass" logo:
2.jpg
2.jpg (13.24 KiB) Viewed 2344 times
This was done with a sticker as template and a hobby knife and was probably beyond my skill but it worked. After some seriously tedious cutting and shaving I taped off the back of it, then flood filled epoxy in multiple passes, then sanded down the front surface to remove excess. What this does is diffuse light nicely like stained glass on a church window. The problem with epoxy is no matter what you do there are tiny little bubbles in places, so I embraced it and mixed as hardening to make them uniform everywhere. I really like the look of it especially when it's lit. For the backlight I originally got some big powerful RGB Leds and drilled up an acrylic sand paper diffused light guide with aluminum foil glued all around. I drilled holes for the LEDs to go in, and planned on including an ATtiny with a button you could cyclically go through different colors with the RGBs maybe even pulsing/etc. In the end it was simply too large to all fit over the Uzebox PCB, sucked as it was a big chunk of wasted time, so I went with Electroluminescent "tape". This stuff is a single color that looks great, pretty cheap, and is very flat. The downside is it requires to fit a step up converter for voltage and the tape itself has an audible hum when it is operating.

The only thing different than most Uzebox PCBs is that nothing is socketed, the SPI ram package is shaved down for clearance, no buttons nor LED are soldered in(hence the external ones), power barrel leg is lifted and routed through switch first, and controller sockets are not installed since they are put in the casing. Keyboard interface parallels off player 2 socket, but I need to add a switch to optionally turn it off. The modifications to the keyboard might not look like much but they are pretty significant time wise. The only reason it works at all is because of the curvature of the keys of this model keyboard, and a tunnel needs to be cut and many things shaved down to fit in that space. I will throw up more detailed photos of assembly later. So anyways they are coming to life and I plan maybe 3-5 total eventually. They will definitely all be personalized for the owner with the sticker plaque like "D3thAdd3r's Uzebox 128", and if I devise a better way to cut out the lighted part, perhaps lighting on all. Lots more to do and show but this is a long post already.

User avatar
Jubatian
Posts: 968
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox 128+

Post by Jubatian » Tue Apr 05, 2016 6:34 am

Nice collection, and all with a box (well, expect the TV Computer - I guess an original box for that thing in a sane condition would cost more than the machine itself :D ). That Mattel Aquarius is quite a rarity, I didn't even knew about it. The grey brick was also odd, for first impression some Amstrad CPC variant, but then I looked it up. Well, there is some connection, it is an Amstrad machine, just a Spectrum after they acquired Sinclair.

That Uzebox 128 seriously demands some fitting firmware... I have SPI RAM in mine as well, maybe will experiment with this sort of stuff. To get something done which works it out all from RAM using some kind of interpreter. Just too many things I am already doing.

For the "audible hum" part... On my TV, the Uzebox produces a persistent very faint hum, I guessed it was normal, probably something coming from the 50Hz mains. If this isn't any louder than that (at low volume set on the TV), probably passable. How it didn't fit in the keyboard? I would think it had plenty of room in it sideways, or maybe it was a design mischoice (that you already fixated the Uzebox PCB below the LEDs when it became apparent).

User avatar
D3thAdd3r
Posts: 2213
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r » Tue Apr 05, 2016 11:45 pm

Jubatian wrote:Nice collection, and all with a box (well, expect the TV Computer - I guess an original box for that thing in a sane condition would cost more than the machine itself :D ).
Some things just aren't practical to get the box but either way retro computers are great to collect; I do best effort within reason. Atari ST, Vectrex, how did all those boxes disappear? Boxed Odyssey 2 with everything, OK choose from 15 available any time for $60. Macintosh SE with all papers/upgraded ram/etc. $150 shipped any day of the week. Want the box too? $900 when Churyumov-Gerasimenko comet is visible, requires a signature in blood, and some form of commitment to the devil IIRC.
Jubatian wrote:Well, there is some connection, it is an Amstrad machine, just a Spectrum after they acquired Sinclair.
Nice totally right, a ZX Spectrum +2(B).
Jubatian wrote:or maybe it was a design mischoice
Yes it was a mistake I didn't do enough test fitting as I built vertically, probably possible to do evenly lit horizontal somehow, but I raged and ordered ELs. More reading on it, Adafruit says the noise comes from the AC driver box, and suggested you could pad that box to potentially make it quieter. I don't think it gets picked up on the audio to the television at least. I will try the padding idea which I feel optimistic about. Otherwise it seems just loud enough to warrant a dedicated on/off switch. It's a fairly high pitched sound around 1000hz. I think I wont try LEDs again because it is just too much work.
Jubatian wrote:That Uzebox 128 seriously demands some fitting firmware
This would be ideal especially an interpreter could allow a real operating system. I don't want to develop anything angled as a derivative console, if I even imagined I was capable of such, just a convenient package that allows the expansion stuff to be there from the start. Really trying to legitimize the expansion stuff and I think it will pay off eventually. So far all my work towards it software wise I have nothing to show for it.

Unless someone has convincing ideas, I am not going to break out the expansion port. I think with Uzebox Jamma and the expansion module, there is no more add-ons coming since there is, what, a couple orphaned pins at most left? I will probably wire unused pins to unused pins on the controller ports, so it would be possible to use SNES multitaps or other devices needing that I/O bit. I am experimenting with a headphone amplifier, which I'll do standard if it works to make it nice for music/tracker development. The potentiometer would go in the hole the PS/2 cable used to go through. Other than that I should shut up until I get a few of them released into the wild. Suggestions are always appreciated, I love a good brain storm.

User avatar
uze6666
Site Admin
Posts: 4338
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox 128+

Post by uze6666 » Wed Apr 06, 2016 4:00 am

Hehe, awesome Lee, it has come a long way since that sneak peek. :D There's a lot of work going in there!

As for the expansion port, I had a couple ideas for the remaining pins on a Uzebox computer. Somewhat like the BBC or Apple 2 back then, it could control arbitrary things like a robot arm, a voice synth, etc and such. I have a 3d printer so that could put it to good use. :ugeek: Or it could use the current "Uzebus" dedicated to the ps/2 keyboard and (upcoming ;) ) mouse.

hpglow
Posts: 269
Joined: Wed Apr 14, 2010 6:06 am

Re: Uzebox 128+

Post by hpglow » Wed Apr 06, 2016 5:11 am

You could always use extra pins to talk to a second avr :)

User avatar
Jubatian
Posts: 968
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox 128+

Post by Jubatian » Wed Apr 06, 2016 7:06 am

I was thinking about the firmware aspect a bit... Maybe it is viable.

I already did some experiments with the Mode 2 concept, which showed it should be definitely possible to create a Mode 2 style video engine at 8 cycles per pixel (thus matching the pixel clock of many old systems such as the CPC), and using a different concept for sprites to eliminate the need for ridiculous amounts of RAM and CPU time to pre-calculate them. In these concepts I use code tile style render for both the sprites and tiles, so this mode would be large in ROM usage.

By this I thought about a RAM only video mode with the following rough features:
  • Two row modes: either 20 tiles attribute mode or 40 tiles straight, both needing 40 bytes of VRAM.
  • Width is at most 320 x 4 cycles. The 20 tile wide attribute mode is Mode 2 style supporting sprites, the 40 tile wide is simply mostly for text or monochrome concepts.
  • 1K of VRAM, so supporting 320x200 (40x25 tiles), or 160x200 in Mode 2 with sprites.
  • 2K of Tile RAM for 256 tiles, also used for sprites.
  • 256 bytes Palette buffer to realize 16 color graphics (so in attribute mode you can specify FG and BG colors). With Mode 74 style tricks, this can be largely hidden under stack.
  • Width can be reduced, horizontal and vertical scrolling possible in a similar manner like Commodore VIC.
  • Split screen possibilities (necessary to have both 20 and 40 tile wide sections since you can't do "racing with the beam" as the AVR is completely utilized in the video).
  • By my experiments probably even as much as 8 sprites at 8 pixels width should be possible on a scanline. 8x8 sprites, monochrome, using tiles from the Tile RAM.
So something around the lines of this. Probably it would also be possible to get 4 color alternative row / sprite modes at the cost of having only 128 tiles + sprites (fitting in the 2K Tile RAM). Another useful feature could be a Character ROM based 40 tile wide text row mode, so you could have text alongside graphics without limiting the latter. For sprites I would go the NES & Gameboy path, to have like 40 total defined, of which 8 can be displayed at one scanline (will see the possibilities, with none or little pre-rendering with little RAM use this is tricky).

This graphics mode of course is quite limited compared to normal Uzebox modes and would gobble up lots of ROM with everything implemented, but it could be quite useful coupled with the SPI RAM holding graphics assets for animations and likes. And a good RAM based graphics mode is definitely a fundamental part of getting a firmware done for this concept (which then becomes different from normal Uzebox gaming: you load programs to be interpreted into the SPI RAM, so no AVR reflashing happens at all).

I don't know what I will do about it, though. Many things to do... (also working silently on my UCC entry :) )

User avatar
D3thAdd3r
Posts: 2213
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r » Wed Apr 06, 2016 8:01 pm

uze6666 wrote:Or it could use the current "Uzebus" dedicated to the ps/2 keyboard and (upcoming  ) mouse.
The only thing special about it, a glorified Uzebox keyboard, is that it is a convenient/clean integration of all available expansions. So if there is real possibilities that in the future would break that claim to fame, then I will have to put some expansion breakout. If it likely wasn't required I would definitely not want it since I don't see an aesthetic or functional place to put it yet. I suppose for most of those things it is not going to be a 2 player game so UzeBus could potentially do all of this? Else I might throw in an ethernetjack with a dongle to break out 8 pins most likely to be used. Personally I like the idea of separate MCUs modules for different external tasks.

@Jubatian, that sounds an interesting mode with that much sprite potential and leaving so much free fast ram. Perhaps the ram and cycles it frees it could be used to pre cache interpretted code since I imagine tight loops and the cost of random access will hurt performance of the interpretted program. Alec showed a high resolution monochrome bitmap mode for the SPI ram but then even a 4 color mode becomes half the resolution there. At least, depending how horribly slow to write, there could be a mode that can do like you say for games and switch back to the "desktop" bitmapped GUI. Might be worth thinking about interlacing then for better vertical resolution?

User avatar
Jubatian
Posts: 968
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox 128+

Post by Jubatian » Thu Apr 07, 2016 5:35 am

I considered using the SPI RAM for the VRAM, as I sketched up the necessities in code for the mode, it looks like possible. However I think it would become a problem when you wanted to actually populate it, necessitating slow SPI (potentially random) accesses. So the optimal layout for this concept rather seems like this, and it is useful even without SPI RAM for normal Uzebox games which would primarily load resources from the SD card (so neither needed large amounts of ROM).

For the interpreted language I am considering something realized in assembler, which would execute the interpreted commands interleaved with the SPI accesses. So sort of pipelining. Coming up with a good language, this could utilize the AVR well (and I think of commands like bulk copies included, so you can carry out such, like loading tiles and sprites into the graphic RAM fast).

SPI streamed graphic mode is possible, but it also has its limitations (it is impossible to get tiles). But with the Mode 2 concept it may work together with sprites, possibly nice for point-and-click adventure games, and of course for any full-screen graphics. 1bpp and 2bpp feels possible at 8 cycles / pixel. Maybe even some attributes fit so you would get more than 2 / 4 colors per line.

Interlacing I think has no much use. At 8 cycles per pixel the pixels are already wide, at 4 cycles per pixel they are neither too much thin. If you start interlacing, you also begin to have minor problems with the audio (currently every frame is 262 lines, with interlacing, you would get 262.5 line frames).

User avatar
D3thAdd3r
Posts: 2213
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r » Fri Apr 08, 2016 2:50 am

Something like emulating a 6502 they say a 20mhz ATmega(that doesn't have to output NTSC+sound) gets a bit more than 1mhz 6502 speed; though that is honoring the internal timing and silicon specific rules like zero page and all that. The interpreted language could probably go faster being designed specifically, not requiring cycle/time consistency, and being higher level. That interleaved memory access idea sounds like the novelty that would be most interesting there; just the type of things people around here seem to appreciate. Well down the road somewhere if you decided to take it on, it would be a pretty cool project.

For a bitmapped desktop mode you have to use SPI ram, so in between waiting, you could probably get higher resolution by interleaving with fast ram. But interpreted makes the fast ram pretty valuable to spend it on that I guess. AttoBasic seems promising and has support for controlling all the ports, peek/poke all memory, etc. It would probably take a lot of modification still to use SPI ram for program storage. Then you might want to have several processes run at once, pausing 1 and pushing its ram to SPI ram, pulling it off when you resume(so not real multitasking since switching is so slow, but the same techniques). Sounds like a big project!

User avatar
D3thAdd3r
Posts: 2213
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox 128+

Post by D3thAdd3r » Sun Apr 10, 2016 10:01 am

Well I spent a day researching how to get better results with less work. I attempted a test to see if I could make the smaller font required for names with > 3 characters and I don't like the precision manually and I'm not confident enough to start on the actual keyboard like this. I nearly bought a fairly big CNC router but decided to take a cheaper experiment instead, since I have no experience to know what I need. I bought a 2.5 watt laser engraver, which is much bigger than most of the toys out there(but still a toy really), that is able to fit something as big as a keyboard. Of course the working window is much smaller but big enough for what I will need. For just ~$400 USD I found a nice enclosed unit from China, ventilated, laser shielded unit with a 40 watt CO2 laser than can cut through the keyboard case in 1 pass, but it appeared it was(being enclosed) slightly too small to hold a keyboard. Size that will fit is thousands of dollars and simply too large until I move to a bigger place.

The much lower spec unit I got for about the same price has only 1 advantage that it can be put up over the top of a jig since it doesn't have a bottom. It's just the smaller working area over an arbitrarily large piece. It also requires wearing laser glasses, doesn't block bouncing radiation, and it lets the smoke go where it will. This is an experiment because it will require many passes to cut through and probably take a long time, but I think it will work judging by wood carving demonstration videos. If not it could at least make nice engraved logos and then I have a better idea how big of a machine to get for my needs. I need to get a CNC machine some day to take on this make hobby more but for now I want to see what smaller lasers can do.

I decided this beast will come with matching controllers but I am not going to do much work to get them that way...These controllers are replacements for the Retron console and they are the right color scheme already. I carved a logo in an SNES controller and it was much easier than the harder keyboard plastic. I bet the laser engraver will be able to make a very nice carving I could either just leave a depression or try to mask and actually paint inside(probably leave it). So in theory they will look like this without the extra color:
uze128 controller.jpg
uze128 controller.jpg (21.44 KiB) Viewed 2121 times
Here is a picture with a revised button layout:
uze128newlayout.jpg
uze128newlayout.jpg (104.19 KiB) Viewed 2125 times
For the expansion I mentioned a ethernet/Cat5 data jack which gives 8 pins and would be very clean and small. I would think just +5/Gnd/MOSI/MISO/SCK/PB1/PB2/PD5 are needed and I would break out PA5/PA6 to the 2 unused pins on the controller sockets since these seems to be reserved for advanced controllers attachments per this helpful page. I might just do it and hope it's good in the future, even though it would require a custom adapter. Before I lose my mind overthinking this yet again, does anything seem wrong with those 8+2 pins? Seems most other things are spoken for now with SPI ram+ESP8266.

Here is a picture of the bottom of the one I'm currently working on. It's just rough cut for now, I will go back and smooth it out. This was required to get things to fit, and it just barely clears vertically as it moves away from the back wall. There is no choice but to attach an additional bottom to the keyboard so that the circuitry isn't seen and is protected. I made up a plastic sheet for the first attempt with cutout so the elevation legs can still be popped out. A real pain is having to put screws upwards through the plastic to mount the PCB precisely. I haven't found flat head screws that work out and also it then requires being countersunk holes. It's hard enough to line things up correctly already and don't want an additional step so I am thinking about using something like a 1/8" rubber sheet cut to this same shape:
uze128bottomplate.jpg
uze128bottomplate.jpg (152.62 KiB) Viewed 2125 times
And then using regular machine screws and simply grinding out some space in the appropriate rubber areas for the screws. They will then still be able to have the rubber flat against it and be unseen until the rubber is removed for service. I do think it will look fine, be taller, and would be non-slip also, I will try this and show what it looks like mounted to the bottom. I would also like to increase the overall weight of the device and am almost considering small metal weights to do so. That is more of an emotional appeal thing than logic, but things just feel higher quality if they are heavier and I've seen several real devices do this. Currently this thing is a mere fraction of something like an Atari ST, Amiga, etc. As usual forgive the fact that I do half my thinking out loud on the forums :roll:

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests