I know this thread has been pretty dead for some months and I would like to apologize a bit to @dw817 for kinda just ignoring many of his original ideas, such as the two green and pink sprites, the four character text display, etc. I still stand firm in the idea that 4KB would be better, Although after learning about the 6507 (the chip used in the Atari 2600, it was basically a 6502 but with only 4KB of memory) I'm not as concerned about wasting that one nibble in full addressing.
I still think this is a really good idea that would be really fun to implement, but I think that I am not the one to actually program it, depending on what kind of interface would used, anything even remotely close to the pico-8 insterface is beyond my capability.
Hope this thread can make like a zombie and be not dead anymore.
: )
Hi @Matcha155.
It is me that should be thanking you ! :)
You guys have upheld this thread for so long when all I had was just a few simple ideas on a 256-byte system.
If you want to add to the mix, as I considered this to be a handheld device, I also wanted to have 8-LEDs, all different colors, once again taking a single byte to light all 8 of them up.
When I came up with the 4-letter message idea, I abandoned the notion of colored lights as that would be more than enough to relay information to both gamer and developer.
. . .
As for the gist of the conversation you guys are now talking about, while I may not be able to contribute to its depth and complexity, I can certainly read and marvel.
So for all of that, thanks !
That is terribly kind of you, @Matcha155. I appreciate your interest ! :D
As mentioned the resolution is 16x16 B&W. The PINK and GREEN are single pixels that appear atop of this.
Here now is a demo I made to demonstrate.
Use the arrow keys to navigate. Press 🅾️ to plot a pixel here. Press ❎ to swap between drawing with the PINK or GREEN sprite.
There are only 2-hardware sprites in the system, the PINK and GREEN pixels. The rest of the pixels lay "beneath" these sprites, the 16x16 black-and-white pixels.
When a MESSAGE happens, the 4-characters. It ignores the screen entirely, clears it, shows those 4-letters centered using 3x5 font yielding 15-pixels across and 5-pixels high, pauses for about 1 second, then returns the screen exactly as you left it.
This is considered a "hardware" movement and the system does not actually contain the memory for the 3x5 pixels to comprise the font.
Please let me know if you have any further questions regarding its design and function.
Hi @Matcha155. Well it's not set in stone. :)
That could be removed in favor of my earlier idea of having 8-small colored LEDs.
Purple, Red, Orange, Yellow, Green, Aqua, Blue, White.
If the red LED lights up for instance without you calling it, it could represent an error in the code whereas green would light up if the code ran and ended properly.
The other idea I had earlier to that was to have the standard calculator 8-bars led "8" with the decimal. You would have four of these. Two red, on the left. Two more green on the right. To keep track of scores and items.
Hmm, ok hear me out, make the screen 22 by 16. The part of of the screen mapped to memory (still black and white) starts at 3,0. On each side there's a band of pixels (y position 1 on the left and y position 17 on the right), that act as less, put still allowing the same crispness as normal pixels.
also I was wondering if you want to go the way of the Atari 2600 and possibly have the user handle raster drawing themselves, to give them different options resolution and color, for example you could have a 16x8 main screen with four color (say black, white, light grey and dark grey). Although the user would have to sacrifice some code and memory to achieve this.
I'm - a little confused as to what you are stating here, @Matcha155.
The screen could be 22x16. I'm not understanding the band pixels ?
The idea I had in mind was for this to be a physical handheld device. The input would be the 16x16 block pixels themselves. It was a touch-screen and you could use a plastic overlay to show a virtual keyboard like the Intellivision did.
To load and save data, you connected two units together and it flashed a light at a low baud so you could transfer your code to another unit just like it.
All 256-bytes were read and saved.
A simple PAINT program would be one that would light up or take away the light for any of the 256-positions. Pressing any of the 4-corners of the 16x16 field for longer than 1-second would bring up the editor and/or diagnostics.
It could also have a USB slot so you could build the code directly on a computer, far easier than to use its on-board code editor.
The idea was beyond touch-screen, @Matcha155. Basically transparent buttons that had a nice feel and click to them. Like a plastic overlay where you could see the lights beneath. Whether black, white, pink, or green.
Also you could slide an opaque plastic insert over either the top 8 or bottom 8, to show a keyboard of sorts, unique for each program.
16x16 so 256-buttons in all.
If that's too far-fetched can stick with simple NES controller. Up, Down, Left, Right, (A), (B), Mode - and plays on your television screen.
Personally I think this is very much far-fetched.
The band I'm talking about are a simulation of the LEDs. The actual screen (black & white, bitmapped to memory) is still 16x16. But there are now horizontal margins, which contain the "LED"s (not actual LEDs) but pixels controlled by the PPU.
How many pixels, @Matcha155 ? What did you have in mind ? I'm curious now ...
It costs one byte per PPU pixel if it overlays the 16x16.
It would be bits, @Matcha155.
And either a single byte would return which key was being pressed at the time or they could all be read in tandem via 32-bytes as single bits. (32x8=256).
Open one up, @Matcha155, and I will be more than happy to attend. :)
Here it is https://discord.gg/9DphPtT3. I made more channels than necessary probably.
[Please log in to post a comment]
