Yea that is exactly what i meant with "connect the high bit of each 2-bit DAC together", but I didn't have access to a PC so I couldn't make a fancy circuit diagram.

Alao this means I could've saved 2 pins on my CPLD by doing that connection in hardware... dammit, need to remember that for the next one.

Garth, that went way over my head It looks fancy, but I do not know how to reply. Thank you though.



Spot on George. I tested that configuration and it is quite pleasing! I had to modify some values to accommodate for my grounding the monochrome and 4-color resistors, but the setup is a good one. I got R+I=(250,82,82) and R-I=(168,0,0). So basically a deep red and a dull pink. There is good contrast between them, and yet they both still look "red". Also the two greys are different enough from one another, and different from white and black. Thank you!

As for the diodes, I also tested that one:

https://falstad.com/circuit/circuitjs.h ... hv7dkBkGgA

And I'm finding a configuration that would supply R+I=(250,0,0) and R-I=(153,0,0). A full red and a mid red. Like you said, 'bright black' is still just black, so only 15 colors, BUT those 15 really pop!

My biggest worry is which diodes to use, based on:
1) Switching Speed
2) Resistance
3) Thresholds

I see from falstad that it would need to be able to push 1.9V through the diode, I don't know if that's a good thing or not (and I know I'm not using correct terminology here, I'm new, forgive me). Also the resistance the diode has must also be considered, as the diode circuit is much more sensitive to these values.

I have some signal switching diodes at the house. I definitely want to breadboard this to make sure there is enough of this and that to make it work. Any particular suggestions for which diodes would work best for this application? I haven't worked with diodes very much so far.

Thank you all! Good discussion!

Chad

EDIT:

I attached a picture of the two different palettes. The top one is resistors only, the bottom one is using the diodes also.

I don't really understand the circuit with all the switches, but great if it works!


I haven't put these diodes in before so I'm not sure, and don't know much about choosing diodes. I might experiment a little later, it'd be a good excuse to get my electronics stuff set up again!

But you're right, you'd need to choose well. Generally the diode will have a fairly specific voltage drop. One option here is to go very simple and just make a regular voltage divider for each channel, but also connect each output to the intensity input through a diode with a low voltage drop, e.g. 0.3V (note this is lower than you get from most silicon diodes). This means that your high-intensity output will be at 0.7V, and your low-intensity output will be 0.3V lower, i.e. 0.4V. This would probably look quite good - a little too dark perhaps. Here's an example of that:

https://falstad.com/circuit/circuitjs.h ... FIJs0s+iAA


Another option is to do the diode bit at a higher voltage range, then divide down again afterwards. My old circuit kind of already does that by having the extra 220 ohm resistors before the output goes to the monitor. In this case you can use a diode with a higher voltage drop and still get a good result like this:

https://falstad.com/circuit/circuitjs.h ... kxCNJvmwgA


I can't vouch for this being a good idea though, and you will need diodes that can switch fully at the right frequency.

Looks great George, thank you. Yes, that's what I'm thinking about. I'm still debating if I should go with all resistors (your previous model) or the one with diodes (this model). I also experimented with RRGB 4-bit colors, and what that would look like using GIMP. I really like that one, it gives a REALLY nice variety, but it doesn't have grey, so... take some, lose some.

Sorry my link is full of silly extra switches. I have 7 shift registers going into these 3 colors, and I have to account for all the extra grounded values. 330 ohms total is the sweet-spot for each of my three 'color modes' it seems, so I change accordingly.

Onwards:

Attached is my new Monitor demo! And the requisite picture of course.

It is a funny little thing, not optimized at all. Simple commands:

(XXXX) changes the 'cursor' location
[XXXX..YYYY] changes the 'selection' locations
XX YY ZZ writes hex values into memory, starting at the cursor location
M moves memory from the selection area to the cursor location and beyond
R runs (rather, it JMP's) to the cursor location

You can get really funky with it too, with weird commands like:

[80.81(40]FFMR

I don't know exactly why someone would want to do something like that, but it is possible I suppose The idea is that it doesn't "break" if you put weird things in there, it just does its thing.

You can also use the arrow keys to move the cursor around, and the page up/down keys to, well, move the current page.

It is VERY slow because I basically re-draw the entire screen each time I move or hit enter. There are ways to make it faster, but I just don't care to do that for this initial demo.

I would eventually like to add Assembly commands, and De-assembly of course. But first, I want to add:

L load from audio input into the selection area
S enters 'SPI mode', a separate interface or something
G lists the games on ROM and lets the player select one

Those commands are soon to come! I want to try to load my bird into RAM, and see how long that takes. Will be interesting to see.

Next piece of pure hardware to check is the RAM and ROM banking. After that... well, Tetris?

Oh, and I know I haven't improved my coding techniques at all, sorry about that. Most of this code was actually written a week ago, I just copy/pasted it in and fixed the bugs. I hope to improve my Assembly skill as I keep going with actual new code.

Thanks everyone! I appreciate the help and feedback.

Chad

Attached is the latest Monitor program, it now includes "L" command, to Load from 'cassette' audio input.

So I converted the bird data into a binary file, then changed my 'AudioPacket.cpp' program to take a file instead of my hand-typing everything.

It took the computer (no lie) 4 hours to convert 30K into a .wav file that is 53 MB in size. Wow. I even made optimizations to the code to speed it up!

I typed this command on the monitor:

[0600..7000] L
(C000) R

I have a little "copy RAM to VGA" program at $C000 btw.

Then I hit play on the desktop. It is a 4 min 30 sec audio file, but I only loaded 4 minutes of it. And as you can see, it came out beautifully. I recalculated everything, and it seems to be an 888 baud rate, because I'm technically sending 9 bits in duration for each byte of data. I know this is no way shows it's accuracy, but I've been testing that manually along the way.

I do have to say one thing though: Last night I was messing with this, and I was getting BAD results. I would get random pieces of data, nothing at all as expected, the volume changed what was being read (that shouldn't happen on this circuit), and I was just confused. I put a scope to it, and everything seemed fine. I went and tested it again, and it worked. I didn't do *anything* and it was not working, then it was working. I totally blame my desktop computer, it has been acting weird with the audio line-out for some time. I just didn't know how badly it had gotten!

Next up is SPI support. I'm thinking I will code it in very similarly to this audio loading stuff. We'll see, still debating on that one.

Thanks everyone!

Chad

I didn't think it would only take a few minutes, but SPI EEPROM is now working.

New and updated commands:
L = load audio input
W = write selection to EEPROM
R = read selection from EEPROM
M = move memory
J = jump to place in memory (JMP to run new code)

I currently have an 8K 25LC64 SPI EEPROM on the board, and so you can only save the data from $0000-$1FFF onto the EEPROM right now. That's good enough for the demo, if I get a bigger EEPROM it can go further. I have a slot for a second EEPROM, but I think I'll handle that one differently (like, save where you want).

Whelp, that's it! Seriously this time. I can't think of anything else in particular. I *do* want to clean up my code, and perhaps I'll bundle something together and post it on github or something: schematics, gerbers, demo code, pictures, etc. I will also be making a board revision to adjust the resistor values some, and other nit-picky things I have found along the way. Very minor.

I would love to work on the SD card implementation, but I'm burning out. It's been a long week!

Thanks for hanging in there with me. I'm done now, seriously Have a great day guys!

Chad

Here is the link to my github page:

https://github.com/stevenchadburrow/Acolyte6502Computer

I think I put everything needed into the ZIP file. It does not contain all of the demos, but does have my Monitor Assembly code and my extra C code.

I've been thinking of making a Youtube video on how to demo this thing. As if someone has already constructed it, and I could show them the first steps to using it. Would be neat! I have all kinds of ideas on how to make it user friendly.

Thanks everyone!

Chad

Great progress. One possibility, if probing a circuit changes its behaviour, is that there's a bad connection or dry joint, and the pressure of the scope probe is making the connection, or improving it. Another possibility, less likely I think, is that the extra capacitance is making a difference.

Not sure if that has been brought up: https://sites.google.com/site/h2obsessi ... bi-s-video
A description to go from RGBI digital to analog RGB video signals.

I've also got some good results with the schematics of the Ultra-PET CPU board (https://github.com/fachat/csa_ultracpu see bottom of page of colour example (w/o brown fix), and here https://github.com/fachat/csa_ultracpu/ ... -sch-4.png for the schematics - just note I haven't implemented or tested the brown fix yet)

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Those are excellent links! I see your 'brown fix' and wow, it is actually easier than I thought. The other link is really good too, that is exactly what George and I had been discussing. I see now there are a variety of ways to do it, that's good to know, very helpful. Also, thank you for showing me what diodes you are using (in your schematic), so that I know what type shoudl work! Thank you.

Ed, I am just as confused. I really feel like it's the PC's fault on this one. Sometimes when I switch between headphones and speakers, I get this weird echo effect, so I scroll the volume from 0 to 100 back and forth a couple of times, and that normally fixes it. I could have been having that issue, but I couldn't tell because the audio was connected to the 6502! I tried many things, I think I tried doing that too, but who knows. Later, I was able to send minutes of data without issue, so I'm not going to worry a ton (yet).

As I was testing things out yesterday I decided to convert the Bird.wav into Bird.mp3, and see if I still got clean data. NOPE! I definitely sent a bird through the audio line, but it was mis-colored horizontally. I would have horizontal strips of pink, and then blue, and then perfectly fine normal colors. Again, could it be my computer again? Maybe. But it was actually sending a bird, it was just slightly wrong. Goes to show the 'lossy' format of .mp3 is not good for data.

Thanks!

Chad

It was interesting to see Andre's brown circuit. I was thinking you could do the same using two NOR gates and a diode. (Edit: I was wrong) But most of all I wonder how much of an interesting palette you could get through creative use of 74138 decoders!

Edit: Actually 74139 could be better. Each two-to-one decoder could drive five distinct DAC levels, by wiring all their outputs through resistors. Then on the input side each gets three of the bits. I think you could get some nice variety out of it.

Note, I copied the brown fix from some websites. I saw multiple sites with the same schematics so I thought it's some kind of standard and didn't attribute, sorry

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Attached is an updated Monitor program, and requisite picture.

It now has a 'full' disassembler built in! The ! command makes the start of the code happen wherever the (XXXX) cursor is currently.

It does not yet contain any zero-page instructions. Mainly because I'm lazy, but also because their addressing modes confuse me

I've been pondering how to do the Assembler part. I think the parsing would be easier now that I know how these addressing modes kind of function. My biggest issue is: How do I display an error? Currently there is never any errors, it just ignores things that are weird or incomplete. But obviously there could be wild errors when actually typing Assembly. Do I ignore only that instruction? How do I know if the next one is ok or not? How will I know if I messed up while coding? Lots of issues besides just parsing.

I also plan on adding a ? command that displays a helpful guide on how to use this program. Would be nice built in!

Thanks everyone. I'm starting to make a miniature operating system here

Chad

After a bit of helpful critiquing here:

viewtopic.php?f=2&t=7110

I'm back to present a MUCH better 'monitor'. I don't know if I'd call it a monitor at this point though. It is closing in on an 'operating system', maybe just an 'assembler', definitely a replacement for BASIC.

I switched the Disassembler to the left side where it is more important. I removed all that 'cursor' and 'selection' stuff for the memory, instead going with straight 4-letter commands that expect addresses and stuff later.

I took hints from SMON (https://www.c64-wiki.com/wiki/SMON) and others for the Assembler mode. It's not a copy/paste at all, but it does mimic functionality. You can type Assembly code in, and it will accept wild variants as well. For example: LDA#44 will work just as well as LDA #$44, and STA4444X will work just as well as STA $4444,X. So it is a flexible Assembler. You can also 'realign' the top of the code at any time, and also write out a sequence of hex bytes. Because the code and memory are drawn independently, this speeds up coding a LOT.

Any zero-page assembly and disassembly functions are still not included at this point. That will come later.

There are currently no 'find' or 'hunt' or 'compare' commands, mainly because that would have to return a value to the user, and I'm not exactly sure how I want to display that at this time. The command HELP shows all that I currently have available.

Creating the Assembler code was actually VERY easy, once I had a good idea of what to do. Sometimes I type code at work in Notepad, and because I can't test it, I have to be very careful, and go through it a few times before I'm happy. Then I come home, and it mercifully works nearly every time! At least it works enough.

The attached code is NOT YET COMMENTED. It's still a work in progress, I'm only including it for posterity sake.

Thanks everyone!

Chad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!