Vulcan-74 - A 6502 Powered Retro MegaProject

[BigDumbDinosaur]

jsii wrote:

Okay, some thoughts...

What you are lamenting is the manifestation of the "instant gratification" mentality that has infected a lot of young people. No one, it seems, wants to be economical with system resources because "it's too hard," or "it takes too long," or...

In the 1990s, I wrote the Warehouse Information System (WIS), which is a vertical application for use in building materials distribution. The environment I used was Thoroughbred Dictionary-IV, which is a so-called rapid application development system built around the Thoroughbred BASIC runtime engine (a type of timesharing BASIC). This mess runs on top of UNIX and Linux, and there is also a port for Windows (which no one in their right mind would use in a transaction processing environment). When I started on WIS, I was going to use the full 4GL features of Dictionary-IV, as I was envisioning a fairly easy development curve. However, a funny thing happened as I dug into it.

I've been writing assembly language programs since the 1970s, and have gotten accustomed to the detailed control that assembly language affords. I couldn't get away from wanting that control as I wrote WIS, and the damned 4GL stuff kept getting in the way. Also, I discovered that when I compiled my 4GL code I had a serious case of bloat going on. Adding insult to injury, the OOP style simply didn't mesh with my thought processes.

So I got away from the Dictionary-IV 4GL features and "regressed" to 3GL code (Thoroughbred 3GL programs compile to "T-code," which is compact and economical in system resource utilization). The programs got much faster, I had more control, especially with the user interface and best of all, I was enjoying writing and testing code, because it was (mostly) doing what I wanted. Yes, it took longer to write the many modules that make up the package, but the end result was what I wanted.

To me, a high level language is a luxury. I've written entire database engines in 6502 assembly language, so big, complicated assembly language programs are not at all daunting to me. That must make me a dinosaur by the standards of the Raspberry PI and Arduino crowd, but then, they are lightweight programmers by my standards. So I guess we're even on that score.

So don't be discouraged by the instant gratification crowd who think that bare metal programming is something only done by people stuck in the past. There will always be a demand for programmers who know how to twiddle chip register bits and analyze the processor status register. We have quite a few of them right here.

[BigEd]

There's a piece here from 2011 advocating that those wishing to program console games should learn some specific things, and points them at some resources. I think similar things might be good for people programming some of the lowest level firmware for embedded computing.

Quote:

a list of things I believe all console programmers (and recommend to all programmers as good reading) should fully understand with links where possible

[Oneironaut]

Had some time to dwell over the way Vulcan-74 will boot / load from an external SPI Flash memory cartridge.
Now that it is back to being a 6502 only project, I may add a tiny 2K Kernal ROM.

My last revision was going to have a 7400 based logic section that would initialize the SPI Flash and then start serializing its entire contents to all of the on board SRAM... Sprite Memory (1024k), PlayField Memory (1024k), Sound Memory (512Kx4), and Program Memory (64K). This would work fine, but requires a large amount of glue logic, and limits the Sound and Graphics to only what will fit into the SRAMs on bootup.

If I go with a tiny 2K Boot Kernal, I could have the 6502 then take care of doing IO to the SPI Flash, and then use any size Flash to store Sound and Graphics Data. The 6502 would then load up the SRAMs with whatever it wanted. A graphic intensive game could have gigabytes of images stored if required. Full music playback would also be easy. This also removes the glue logic needed to un-serialize the SPI back to parallel data and issue the Mode 0 commands on boot-up.

The only downside is of course, the ROM. I don't like ROM.
But, I do have a drawer full of 55ns 4K ROMs handy, and they seem to still be commonly available components.

To code a simple "Kernal" that would display a "Loading..." message on boot-up, and then load its own program memory with the real code should only require 2K at the most, maybe even less.

This would require my Memory Decode System to handle 3 segments (SRAM, ROM, and IO), but would actually be less complex than the scheme I have now that has to share the bus with the external Loader System.

I am going to try using a single 74HC85 Magnatude Comparator to do all of the memory decoding.
The memory map will be...

RAM : 00000 to 63231
IO : 63232 to 63486
ROM : 63487 to 65535

I will then tie only the Hi Address bus to the 74HC85, and set it to compare value 247.
Since the 74HC85 has 3 compare states (all active low), RAM is (<), IO is (=), and ROM is (>).
I will just tie the compare states to the CE on RAM, ROM, and on the free EN of the IO decoder.

RW qualification will be as normal.

In theory, this seems workable, but I will have to wire up a test and see.
I wrote a ROM writing program using an AVR and have a test program in the AT28HC64B ROM now.
If this works, then I will code up a nice Boot Screen and SPI reader next.

I am also considering a keyboard instead of a joystick.
To keep to my "retro" game-plan, I will just rip the internal circuitry and hack into the matrix (Neo?).
This way I am not relying on PS2 or crazy USB solutions that require more power than the entire video section.
It is very easy to rip out the keyboard circuitry and just tap the matrix points on any keyboard.
A few 74HC574s and you can interface directly.

Lots to consider!
Still enjoying this project!

Radical Brad

[BigEd]

To keep the SPI hardware minimal, you'd bit-bang from the 6502 - I think that's what you're doing. But, you say you don't like ROMs. So, instead, you could add a little TTL to make the SPI access much simpler for a byte-oriented CPU, and minimise the ROM to the point that you can build a hard-wired boot ROM with diodes. That would be hardcore!

[GARTHWILSON]

Quote:

I am going to try using a single 74HC85 Magnatude Comparator to do all of the memory decoding.
The memory map will be...

RAM : 00000 to 63231
IO : 63232 to 63486
ROM : 63487 to 65535

Hex sure makes it easier to understand:

Code: Select all

RAM: 0000-F6FF
I/O: F700-F7FE
ROM: F7FF-FFFF

(although I suspect you meant for the end of I/O to be at F7FF and the beginning of ROM to be at F800).

[barrym95838]

Brad, please explore the potential benefits of using half of the 6502's zero-page for your I/O. You may find that it's an overall win.

Mike B.

P.S. This thought isn't fully developed, but I'll throw it out here anyway. Has anyone here explored the possibility of mapping I/O to the 6502's vector page $ffxx, and doing away with ROMs entirely? A sufficiently agile I/O system could provide the needed vectors and the executable code, re-configurable on-the-fly, depending on the situation. My dream consists of a map with RAM from $0080 all the way to $ff7f, and I/O elsewhere. Am I delusional? I'm going to prepare a new thread soon, and invite you all to help me build it up or tear it down, as appropriate.

[BigEd]

Thanks for the new thread, Mike!

Exploring the possibilities ... smart I/O

[Oneironaut]

Thanks for the comments.

Interesting idea using zero page for IO. My IO will probably use 64 lines at the most, so this has potential. the only drawback is that I won't be able to use my 74HC85 decode scheme. For that to work, the IO has to be in the middle (above RAM and below ROM). I could drop a 688 on the hi address and look for zero value though.

Hex... I just can't get on board! Still being partly human, I prefer base 10.
I agree, that in an editor, the columns line up nicely, but other than that I don't see the point.

You are correct about the address values!

Brad

[BigEd]

(The advantage of hex is that each digit maps exactly to four bits, and you soon get to recognise what the values are. It becomes obvious that 8000 has just the top bit set, FFF0 has the twelve top bits set. It becomes natural to AND and OR these values in your head. Bits are important because it's bits which are dealt with in address decoders - the fewer the better.)

[jsii]

GARTHWILSON wrote:

I tell ya, I've come awfully close to quitting my job at times when the boss wanted stuff like Bluetooth. After looking into things, I just told him, "If that's what the job is going to involve from now on, then I'm not interested," and at that point I didn't care if he said, "Ok, good bye." Instead, he valued my ability to whip up circuits, especially analog, highly enough to change his plans so I'd stay. When the fun is gone, so am I; and there have definitely been times when I thought I'd rather stock shelves and push a broom or drive a street sweeper or something.

Remember it's just a job, although I walked away from the phone industry quite a while back and I don't regret a second of it.

Quote:

Garth, I read the articles and I went to your website. Very good material.

Quote:

Thankyou. There are a few more major features I want to add to the website, but they're all an incredible amount of work, and I'm a little worn out on writing, and I need to get back to building. I'm starting to build myself another workbench computer with more of everything than the current one has—memory, speed, portability, I/O, A/D and D/A channels and with more bits of precision, bigger display and keyboard, etc.. It's a huge job, and it's amazing how many details need to be ironed out before you can start building the main computer board itself. I'm going for a half-rack-width 3U VME card cage (although my pinouts and signals won't be VME-compliant).

Sounds like good work.

Quote:

About the website, very good website, thank you very much. Just how I like'em.

Quote:

Thanks. I occasionally get emails from someone wanting to sell their services to make my site look professional, or asking to buy advertising, something I don't want on my site. I want it super simple while still being as clear as possible. If I were selling insurance or something, then yes, I'd have to have the irrelevant pictures of smiling families in the park, the annoying Adobe Flash things, faded pictures behind the text that make it harder to read, and those extremely irritating viscosity effects!

I think it's better to keep it simple. Downloading 1MB of unwanted garbage just to read a couple KB's of useful info doesn't make sense to me.

Quote:

Went through some of the links.
If I find a place in a design for one of your modules I'll consider purchasing one; just so you know.
Very good work and thanks for sharing. If I'm good for anything, let me know.

Quote:

Thankyou. With the price of PCBs coming down and down, it is becoming more realistic to offer more types of little modules, which I hope to do.

Sounds very good.

Quote:

Those in the 'software'/devices industry "feel sorry" for you, Brad (not really), and to them you're nothing more than someone stuck in the past with some archaic "dead" "language" ('assembly', of course, not to mention machine language and the rest).

Quote:

Be sure to see my article, "Assembly Language: Still Relevant Today."

By the time you typed this reply, I already had. A lot of material for comment.

[jsii]

BigDumbDinosaur wrote:

jsii wrote:

Okay, some thoughts...

What you are lamenting is the manifestation of the "instant gratification" mentality that has infected a lot of young people. ...

So don't be discouraged by the instant gratification crowd who think that bare metal programming is something only done by people stuck in the past. There will always be a demand for programmers who know how to twiddle chip register bits and analyze the processor status register. We have quite a few of them right here.

Thank you for the post and for your words. Not discouraged at all. I don't mean to divert this thread's topic with these comments, so I won't try to discuss these ideas in detail. What I'll say is that those "high level language only" people deny reality when they truly think that a high level language skill set surpasses low level skills. They dwell in mediocrity. With regard to 'oop', I'm almost convinced that the 'oop' mindset is twisted. Want to feel the 'lag'? Tie your machine code to some 'oop' work.

[jsii]

barrym95838 wrote:

Brad, please explore the potential benefits of using half of the 6502's zero-page for your I/O. You may find that it's an overall win.

Mike B.

P.S. This thought isn't fully developed, but I'll throw it out here anyway. Has anyone here explored the possibility of mapping I/O to the 6502's vector page $ffxx, and doing away with ROMs entirely? A sufficiently agile I/O system could provide the needed vectors and the executable code, re-configurable on-the-fly, depending on the situation. My dream consists of a map with RAM from $0080 all the way to $ff7f, and I/O elsewhere. Am I delusional? I'm going to prepare a new thread soon, and invite you all to help me build it up or tear it down, as appropriate.

Is there any reason why that wouldn't be possible? am I missing something?

[BigEd]

(There is a thread elsewhere now for that discussion - let's not duplicate it here!)

Please, anyone, everyone, feel free to create new threads when a new idea pops up. Everyone will see them!

[Oneironaut]

Been banging my head on the ROM writer the last 2 times I had an hour to work on this project.
Wrote the AVR assembly to write the 6502 code to the eeprom, and it includes a verify.
Looked over my code, and tested it on an SRAM to be sure. Yeah, it works.

Thinking that I may have found a bad chip (rare indeed), I went and grabbed another AT28HC64B ROM from my drawer.
... still no red LED on to signal a successful verify!

Since I have 20+ of these same ROMs, I tried them all, and all failed!!!
What are the odds???

But then I found this thread, which ironically is here on this site...

viewtopic.php?t=2043

Did I mention I don't like ROM??!? Now those thoughts are multiplying.
I may just go back to my original Loader Logic plan instead.
What's another 50 chips anyhow? Nothing on a board of this magnitude!

Not a productive 2 hours!

Brad

[White Flame]

I'd think that instead of using a ROM chip, you would be one to wire up bits of ROM individually using wire jumpers from an address multiplexer to the data bus.