Acolyte Revision - Schematics and Documents

[sburrow]

Did a bit of coding today, putting in the ability to add a VIA in the future.

Then I had a funny idea: Let's power this board from an external phone battery pack! The kind where you charge it beforehand and take it with you, and you can plug it into your phone to recharge it at some point. Extra portable power. Because I run power from a USB wall-wart anyways, this theoretically could replace it.

And replace it it did! It has been running for over 7 hours now. The battery pack was not fully charged, it hasn't run down even half of what it had. This battery isn't anything special, in fact it was the cheapest one at Walmart. Nothing is hot on the board, everything has been stable, multimeter says it has 4.9V right now.

I had no idea how fuel efficient this board was. This could seriously become a handheld or 'laptop'. Easily. I'd like to see how long it would last if I connect one of those 16x2 LCD's to it though, I figured that would draw more power than my VGA circuit.

There is an update. I'm very amazed! Thanks for reading.

Chad

[GARTHWILSON]

sburrow wrote:

I'd like to see how long it would last if I connect one of those 16x2 LCD's to it though, I figured that would draw more power than my VGA circuit.

The only significant power draw of the LCD is if it's backlit.  A reflective-type LCD (which neither needs, nor has, any backlight) will have negligible power draw.  Something I designed in the 1980's for work used a 16x1 intelligent character LCD and a 65c02 which ran at 170kHz most of the time to save battery power and kicked it up to 1MHz when there was a long string of floating-point calculations to do, and the whole thing, including the LCD, took 2mA.

[Paganini]

I haven't measured, but I think my 20x4 LCD draws quite a bit of current. It's a little flickery, and I feel like my wall wart is struggling. I was thinking maybe I could put a pot on the A/K of the backlight and tone it down. It really doesn't need to be that bright...

[Proxy]

you can use one of those cheap USB Power Meters to see how much current/power it's drawing from the pack. and see how it changes when you unplug things, like the keyboard, or VGA cable.

on another note, having a fully battery powered and portable/arduino sized 65c02/65c816 computer would be a pretty cool project!
i have personally been thinking about something like that for some time, but never sat down and actually design it.

but i would definitely be using one of those TFT-Display shields for Arduino boards to have both a video output and touchscreen input (plus a uSD Card slot) on a single board, without needing VGA or similarly large circuitry. just a VIA and some software routines to handle drawing and reading the touchscreen.

[plasmo]

sburrow wrote:

I had no idea how fuel efficient this board was. This could seriously become a handheld or 'laptop'. Easily. I'd like to see how long it would last if I connect one of those 16x2 LCD's to it though, I figured that would draw more power than my VGA circuit.

Your design is all CMOS and fairly low frequency, so I expect it'll draw 20-30mA. Your USB power bank is probably 5000mAH, so I'd expect it to last 200 hours or so, call it a week.
Bill

[sburrow]

Space Invaders!

Just programmed a Space Invaders clone for my board. This all started because I can't count in hex apparently. I had left the entire $E000 space in ROM open! So, with 4KB available, let's make a game!

Lots of adjustable speed settings to increase difficulty. It took me 8 hours or so to get to this level, and it fills about 2KB of space in ROM. I still need to add the 'mystery' ship, points scoring, levels, etc, but the fundamentals of the game are here.

I think because I coded it so quickly there are a lot of quirks within the code that are indetectable from the user perspective. It's definitely not spaghetti, but I just cannot find a good way to do smaller 'break' statements without (essentially):

Code: Select all

 
some code
BEQ $03
JMP exit
more code

I have some subroutines that do this 16 times! It gets very silly, especially when I'm using labels for the "$03" part (because as65 doesn't understand simple things like that... grrr)

Whelp, one step at at time! Programming this game is fun And my daughter enjoys playing it. That makes all the difference to me.

Chad

EDIT: The picture looks upside down until you click on it? Hm...

[gfoot]

GARTHWILSON wrote:

sburrow wrote:

I'd like to see how long it would last if I connect one of those 16x2 LCD's to it though, I figured that would draw more power than my VGA circuit.

The only significant power draw of the LCD is if it's backlit.  A reflective-type LCD (which neither needs, nor has, any backlight) will have negligible power draw.  Something I designed in the 1980's for work used a 16x1 intelligent character LCD and a 65c02 which ran at 170kHz most of the time to save battery power and kicked it up to 1MHz when there was a long string of floating-point calculations to do, and the whole thing, including the LCD, took 2mA.

I tried running a 6502 breadboard computer from solar power a while back - here in the UK where there's rarely any sun! I seem to remember from measurements at the time that the 16x2 LCD display was indeed using a lot of current for the backlight. But I also found that not powering the backlight at all causes the whole display to not work, so it's not entirely a separate circuit.

The computer ran fine, I think the current draw was around 100mA, but could be remembering it wrong. It had my whole VGA circuit in it as well, though no solar-powered monitor to plug that into; also a VIA and SD card reader. These things all don't use much power really.

[sburrow]

More to update, though I don't know who is reading much anyways. All good either way.

I found a "problem" with my design, perhaps I should just call it a "feature" though. I replaced my 128K RAM with 32K RAM today and got unexpected results!

I had designed to be able to accommodate the 32K only, sacrificing BASIC but nothing else. And I did this in software. So nothing wrong inherently with using only 32K. What would happen is any writes to the $8000-$BFFF region would duplicate in the $0000-$3FFF region, that's all.

But I got some weird writes to $4000 instead... This appears on the screen as stray pixels, and I didn't know why. How could that happen? Well, I was writing to ROM location $C000 (for I/O purposes) which duplicated in RAM at $4000. Hm! I would read from $C000 in ROM and everything was fine. But when I write to ROM at $C000, it *also* wrote to RAM. Dun dun duuunnn!

Why? Attached are schematics, which are probably hard to follow, so I'll just tell you. If I write to ROM, the /WE signal is low of course. But my RAM's /CE is high because of my addressing scheme. As soon as PHI2 falls though, I have logic to enable RAM's /CE line and /OE line (for video purposes), but also disable the /WE line. The /WE signal is behind one extra NAND gate though, so what must be happening is the address and data buses are pushing on the RAM, the /WE is low and ready to go, but /CE is waiting. /CE falls just before /WE rises, causing a write.

That means my 62256-55 SRAM is 'freakin fast'! Super fast. My original timing scheme actually forced the /CE line low far later, and thus it never happened. But I wanted to save chips, and so now it does happen. It could be happening to my 128K RAM, but I wouldn't ever know because the address spaces don't duplicate like the 32K RAM does.

Thankfully reading from ROM does not affect anything at all. I have a '245 between the 6502 and the RAM, which is not enabled while reading from ROM, and not enabled for the video signal, so changing PHI2 does not affect it.

To not have this affect anything, I am no longer writing to ROM at the $C000 location, but now the $FFFF location. This would put any RAM writes on the 32K chip at $7FFF instead, which is technically video memory but off screen.

So! Interesting "feature" discovered! And now it's accommodated for in software. I'd rather not increase chip count just to 'fix' this 'feature'. So, I think I'll keep it That's what you get when you try to minimize a system so much. Interesting things pop up at times!

There's the update. Space Invaders is complete now, and I'm nearly ready to get the next revision board printed. Hopefully it won't be bodgy.

Thanks everyone!

Chad

[barnacle]

It's being read - and appreciated - by me!

I need to investigate your VGA... mine is a character only output and as yet untested - the chips only got here yesterday so they'll need to stay in the aging department for a while

Neil

[kernelthread]

sburrow wrote:

If I write to ROM, the /WE signal is low of course. But my RAM's /CE is high because of my addressing scheme. As soon as PHI2 falls though, I have logic to enable RAM's /CE line and /OE line (for video purposes), but also disable the /WE line. The /WE signal is behind one extra NAND gate though, so what must be happening is the address and data buses are pushing on the RAM, the /WE is low and ready to go, but /CE is waiting. /CE falls just before /WE rises, causing a write.

That means my 62256-55 SRAM is 'freakin fast'! Super fast. My original timing scheme actually forced the /CE line low far later, and thus it never happened. But I wanted to save chips, and so now it does happen. It could be happening to my 128K RAM, but I wouldn't ever know because the address spaces don't duplicate like the 32K RAM does.

Thankfully reading from ROM does not affect anything at all. I have a '245 between the 6502 and the RAM, which is not enabled while reading from ROM, and not enabled for the video signal, so changing PHI2 does not affect it.

To not have this affect anything, I am no longer writing to ROM at the $C000 location, but now the $FFFF location. This would put any RAM writes on the 32K chip at $7FFF instead, which is technically video memory but off screen.

I don't know about your specific chip, but I've done some measurements using 55ns AS6C4008 devices and they seem to return read data in around 35ns. That was in a system where CE was permanently grounded and OE used to gate the output data onto the bus.
Spurious writes would always make me very uneasy. One consideration is that the address lines are not necessarily stable during the time the spurious write happens, so how sure are you that you'll never get a spurious write to a location you actually care about?

[sburrow]

kernelthread wrote:

I don't know about your specific chip, but I've done some measurements using 55ns AS6C4008 devices and they seem to return read data in around 35ns. That was in a system where CE was permanently grounded and OE used to gate the output data onto the bus.
Spurious writes would always make me very uneasy. One consideration is that the address lines are not necessarily stable during the time the spurious write happens, so how sure are you that you'll never get a spurious write to a location you actually care about?

I wouldn't call it "spurious" here. It's target location is very intentional. This all is happening because I'm writing to ROM which shouldn't ever happen, yet I use that "opportunity" to create output bits which do things on the board. Likewise this is happening because I decided to connect BE directly to PHI2. I used to have some logic on the board to keep everything tidy for some goodly time after PHI2 falls, but I took it off and it does still work. There are features that come with it, but they were unknown until I tested a 32K RAM chip which the system doesn't "officially" support anyways (as I lose BASIC entirely).

I've known that this particular 62256 is very fast for a while. Originally I had used my 1008 128K chip and qualified /WE with PHI2 as normal, and everything worked fine. I put the 62256 in and that wasn't good enough anymore! I now qualify /WE to the second-half of PHI2. That only happened because of this darned 62256 chip! It's just freakin' fast, and that's good so that I can test problems that might occur.

Honestly the logic doesn't make a great deal of sense to me. Because I'm qualifying /WE with PHI2 anyways, when PHI2 falls it shouldn't write, but write it does. A combination of fast RAM and slow logic? Still, when this does happen is very intentional, and thus can be regulated.

barnacle wrote:

It's being read - and appreciated - by me!

Thank you, I'll keep writing updates whenever I have them!

Thanks both.

Chad

[Paganini]

Hi Chad,

I'm reading! One thing I find really interesting is how different things push our individual buttons as designers. I remember a while ago you saying something about being scared to try VGA with a character generator ROM. Meanwhile, I would never try your write-to-ROM / memory mirroring thing. Brrrrr. Fully decode my man, fully decode!

[fachat]

The RAM may be writing any time /we is low and not latch it in at the rising edge of /we - which probably makes it so fast. But that also means address lines have to be stable during the whole write and is probably the reason you have to qualify /we with the second half of phi2. If BE gets valid on rising phi2 address lines still have some time before they stabilize at the right value which may be enough to cause a spurious write

[sburrow]

Thank you all for the help on the 'latching /WE' topic (here viewtopic.php?f=12&t=7493).

So I fixed this RAM write issue. I simply qualified the /WE signal with /ROM. Thus, /WE is only enabled when it: A) wants to write, B) is on the second half of PHI2-high, and C) is definitely talking to the RAM (and not the ROM).

Thankfully my "write to ROM for output" uses the /OE signal (making a 'write' high enabled) and so this logic doesn't affect my output scheme.

Sadly, I have to add another chip to the board for this (and I just soldered even MORE bodges!). Not sadly, I can use the extra logic gates to more efficiently carry out the things I had before, and make an expansion port that is much easier to manage. More later.

Thank you everyone!

Chad

[sburrow]

Well, I think this particular board is coming to a close soon.

For the past 2 days I have been remaking my new PCB gerber files. Will probably get this printed within a week (though I said that last time!). Hoping for zero bodge work necessary!

My github has all of the necessary code, schematics, gerbers, etc.

https://github.com/stevenchadburrow

Will update when there is more to update. Thanks everyone.

Chad