That's a good point. I'm not too picky about sound generation, so adding an external device just for sound (rather than embedding a block of known-good Verilog) wouldn't be my first choice.

Something I do like the look of is JROK's multi-Williams JAMMA board http://www.arcadeshop.com/i/1121/williams-multigame-jamma-pcb.htm which is essentially a modern implementation of the logic board of the Defender/Stargate/Robotron/Joust Williams arcade machine. What I like about it is that he went with a real, external 6809, which keeps the design somewhat authentic in a slightly Frankenstein / ship of Theseus way.

A real 40-pin DIP 6502 (to convey the classic roots) attached to an FPGA (and <insert favourite peripherals>) would be a fun toy.

I have written software to generate images of slide-rules, giving the user a lot of options for what scales to use and what marks to put on the scales, etc.. I originally wrote it to generate gcode for CNC milling machines with the idea that a scribe would be used to scratch off dark anodized aluminum (black or dark blue would provide good contrast). Then Don Lancaster suggested to me that I switch to .PDF and use photo-lithography, so I upgraded the program to do .PDF. I haven't actually made any slide-rules --- I need access to a machine-shop --- it is still something that I want to do.

We're getting way off-topic, but this is your topic Hugh, so I'll bite for just a short reply.

Gerber files for PC boards are just text, so I had thought of writing a program to generate the slide-rule markings in a gerber file, have a PCB manufacturer make the parts for me, and take them to my friend's machine shop to do the tongue-and-groove fits. Now you can do things like a binary or hex slide rule, and make it the length of the panels, rather than limit it to 10" scales! I suppose I would have to get the cursor from a pre-made slide rule though. It would be very thick PCB to fit the cursor!

_________________
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?

I started a new thread for building slide-rules.

Getting back to the subject of a game-machine, I do think that the design should be simple so it can be learned quickly. I previously recommended a 320x200 image with 16 colors. I'm not entirely opposed to sprites, if they are simple enough to learn quickly. The idea is to not design the ultimate game-machine --- teenagers need to figure out the hardware --- I would rather have a fast processor and simple design, than a slow processor and a complicated design, even if the latter provides better performance.

I think the processor should be 16-bit (my TOYF, of course, would be my choice, but there are myriad other choices). In this day and age, 8-bit is too hard to work with. For example, the 320 horizontal index doesn't fit in a byte. We don't want the programmer to get bogged down fiddling with 16-bit values in 8-bit registers. Let the programmer concentrate on the game design and programming, not pointless complications.

If you want the programmer to concentrate on putting out graphics without worrying about the complications, then why not just do it on an overpowered PC? The fun of 8-bits is to use simple tools to do clever things.

Less worry requires more powerful hardware to just take care of issues for you. If you aren't running a CPU that can push 10MB/sec of pure graphics data around (not including running the program itself, and the 2MB/sec video output), then the programmer will always worry about making his game run faster/smoother, and make complicated tradeoff decisions.

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

I brought up the hex and binary possibility of a slide rule partly as a joke, and partly because I actually had a remotely practical reason for one recently. PCBs can be made much, much thicker than .062, in fact a quarter inch or more, plenty suitable for milling the tongue and grove. I can't imagine actually going through with it though.

However, the slide-rule thing should just be a little interesting mention here. Since it's not 6502-related, it shouldn't have its own topic on 6502.org, any more than a Z80 computer should. If just two people, or a few people, are interested enough, private messages (PMs) can be about anything, even religion or politics, and can involve several people.


That's one of the things that makes the '816 nice. Even though the data bus is only 8 bits wide, instructions can handle 16 bits at once.

_________________
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?

I respectfully disagree.

Just look at the Arduino community. A vast majority of those project run on an UNO or even Nano compatible version. Those run 8-bit micro-controllers with 2K of RAM. I think teenagers can learn those restrictions.



The Commodore 64 handled this with a mode bit at position $D010. So each sprite had a bit that if set, meant its position would be: Position X + 256. But yeah...can be a little troublesome for younger developers.

_________________
Cat; the other white meat.

But isn't Arduino from the programmer perspective a C machine? (Or indeed, C++.) And it has sizeof(int)==2, usually but not always. Even on an 8 bit micro then, the programmer sees a 16 bit machine.

And I think that's fine - almost all programming is done to a virtual machine, some it is high level and some of it is low level.

You know, you're right.

https://www.arduino.cc/reference/en/lan ... types/int/

I knew they were 8-bit uc's but I had forgotten how much the Arduino libraries shield you from this.

_________________
Cat; the other white meat.

Well, its not so much the Arduino libraries, as it is the compiler abstracting those details away - which is kind of the point of a HLL, after all.
Further, sizeof(int) cannot be smaller than 2 and comply with the relevant standards.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I was under the impression that sizeof(char) must be 1, but sizeof(int) had no similar limitation, as long as its width is at least 16 bits. A certain environment I have in mind has 36 bit cells, so sizeof a lot of simple types gives 1, including char, short, int, unsigned and float.

Mike B.

Indeed, it seems chars are the addressable unit, and are always size 1. There are some answers on stackoverflow about sizes of things in C, which may not all be correct, but it seems that:

and

Theoretically, yes, sizeof(int) could be 1 if char was at least 16 bits. I was assuming char is equal 8 or 9 bits, which is by far the most normal situation

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

You don't need an HLL --- you can do this with assembler macros too.
The AVR8 has 32 8-bit registers, so you can write macros that abstract these into 16 16-bit registers.
Similarly, on the 6502 you can dedicate a portion of zero-page as 16 16-bit pseudo-registers (IIRC this is what the Woz's Sweet16 development system did).

So I was not right when I said: "In this day and age, 8-bit is too hard to work with."
I should have said: "In this day and age, 8-bit is too bloaty and slow to work with. "

Any program that deals primarily with 16-bit data is going to be bloaty and slow on an 8-bit processor --- a hybrid processor such as the 65c816 is going to be a lot better --- an actual 16-bit processor is, of course, preferred.
A game-machine is going to be dealing primarily with 16-bit data --- whether you use assembly-language, Forth or C, you are better off with a 16-bit processor, or at least a hybrid.
I'm not opposed to the 65c816 if it could be upgraded with an OSX prebyte like on the M65c02A --- without that, Forth is too bloaty and slow to bother with.
The OAY prebyte is pretty useful too.
The IND prebyte might be useful --- all I've done with it is to provide something similar to the 65c816's (offset,S),Y addressing-mode --- I might think of some other use though.

Unless you have 65c816 legacy code that you want to run, being compatible with the 65c816 isn't required --- it would be possible to have a processor "in the spirit of" the 65c816 that would be adequate --- Michael Barry's 65902 idea is intriguing.

The TOYF assembly-language is very difficult to work with --- I invented it, and I think it is difficult, so I can only imagine what the learning-curve will be like for other people --- I doubt that many teenagers would be able to figure it out (even among professional programmers, I would expect that at least 50% will run away screaming).
On a positive note though, I would expect TOYF programs to be several times faster than 65c816 or 65902 programs, when implemented on the same FPGA.
If the game-machine is going to be programmed by teenagers, then an upgraded 65c816 or a 65902 would be a more comfortable environment.

I would dispute this. What you have in mind would call for this code(AIUI):

Very easy, I'll give you. two bytes and four cycles(assuming OSX takes two cycles) per 8-bit operation. But the same can be done on existing hardware with:

Which would be three or four bytes and 6 cycles(7 for the push if not in DP) per 8-bit operation, depending on whether you put the data stack in direct page or not. It's bigger, but it is no more contorted than the OSX opcode It's a little slower, but I don't see that being a problem if you run the CPU at a decent frequency. If you can get the thing running at 8 or 10 MHz, you'll hardly notice the difference.

Both require that you set aside X for the data stack pointer, so in that sense they are both equally contorted.
Of course, if you absolutely refuse to use any extra bytes than you theoretically could(because that is what I see you doing here), you could always map some dedicated stack hardware into DP, and then you'd be able to push and pull from A without needing to set aside X at all. Then you'd just STA dp for PHA, and LDA dp for PLA.

And to be blunt, I don't see that Forth would bring in many people anyway. It is not well known, and operates in a strange manner, if you're coming from languages such as C, which are far more commonly known. Include it by all means, but don't make it the only option. I'm interested in fiddling around with Forth, particularly Tali Forth 2, but I'm having trouble getting it to work on my build(the Duart isn't playing ball for some reason, and I'm still attempting to ascertain why).