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.

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

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.

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

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!

Hex sure makes it easier to understand:
(although I suspect you meant for the end of I/O to be at F7FF and the beginning of ROM to be at F800).

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

Thanks for the new thread, Mike!

Exploring the possibilities ... smart I/O

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

(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.)

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.


Sounds like good work.


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.


Sounds very good.


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

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.

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

(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!

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

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.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor