game machines
Re: game machines
One little fun fact about the SNES CPU, the speed is often quoted as 3.58Mhz, however that is the maximum speed. It also can run at 2.68Mhz, and most SNES games were released on cartridges where the cheaper ROMs only supported 2.68Mhz. Like BDD mentioned, it slows down to 1.79Mhz during port access, and also there are DRAM refresh cycles that periodically halt the CPU. Years ago before I knew all that, I tried writing some timed code to make a bit-banged UART over the controller port. You can imagine how well that worked out..
I'm in complete agreement on that. I have a huge fondness for anything using the TMS9918. Especially since my first computer was a TI99-4a and my first console was a Colecovision. My only complaint is that I can't force myself to get serious about the TMS CPU or the Z80. I'd love to tinker with the TMS9918 some, though.
It's an obscure system, but you might like the VTech CreatiVision. It has a 2Mhz 6502, with those TI video/audio chips.
cbmeeks wrote:
White Flame wrote:
From the older 8-bit systems, however, I do have a certain affinity for the sprite setup of the TMS9918 (Colecovision, MSX, etc), which was a very interesting balance for the 1970s. 32 1bpp sprites, either 8x8 or 16x16, hardware multiplexed up to 4 per scanline (and it reports which one it last drew, so you could rotate them out). If you want multicolor sprites, you simply overlay them. Emulators often give the option of eliminating the per-scanline sprite limit.
Re: game machines
Hugh Aguilar wrote:
Most "programmers" are actually script-kiddies --- their primary skill is to quickly "get up to speed" on some software
Memblers wrote:
It's an obscure system, but you might like the VTech CreatiVision. It has a 2Mhz 6502, with those TI video/audio chips.
Yep, I'm familiar with that system. It's on my radar to collect when I can find one. Too bad there weren't many games made for it because those are some good specs for the day.
Cat; the other white meat.
-
Hugh Aguilar
- Posts: 158
- Joined: 03 Jun 2016
Re: game machines
cbmeeks wrote:
Hugh Aguilar wrote:
Most "programmers" are actually script-kiddies --- their primary skill is to quickly "get up to speed" on some software
I meant that, nowadays, most programmers are script-kiddies --- this is well-known --- this is why Python is the most popular language on desktop computers.
-
DerTrueForce
- Posts: 483
- Joined: 04 Jun 2016
- Location: Australia
Re: game machines
I'm pretty sure a script kiddie is someone who doesn't write their own scripts, and just uses ones someone else has written.
If you consider Wikipedia any kind of help, that seems to be their definition.
If this is correct, calling someone who writes their own code a script kiddie is both incorrect and a nasty insult.
If you consider Wikipedia any kind of help, that seems to be their definition.
If this is correct, calling someone who writes their own code a script kiddie is both incorrect and a nasty insult.
- BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: game machines
DerTrueForce wrote:
I'm pretty sure a script kiddie is someone who doesn't write their own scripts, and just uses ones someone else has written.
If you consider Wikipedia any kind of help, that seems to be their definition.
If this is correct, calling someone who writes their own code a script kiddie is both incorrect and a nasty insult.
If you consider Wikipedia any kind of help, that seems to be their definition.
If this is correct, calling someone who writes their own code a script kiddie is both incorrect and a nasty insult.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: game machines
It seems clear to me - but evidently not clear to you, Hugh - that throwing in controversial statements is not a way to encourage thoughtful discussions and mutual enlightenment, or a way to keep a discussion on track. It is a way to get some response, yes, but not the kind of response which ultimately results in cooperative and supportive exploration of a 6502 interest. There are places you can go where the idea is to have an argument, and the more heated the better, but this isn't the idea here.
Re: game machines
sark02 wrote:
Something I do like the look of is JROK's multi-Williams JAMMA board http://www.arcadeshop.com/i/1121/willia ... ma-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.
A real 40-pin DIP 6502 (to convey the classic roots) attached to an FPGA (and <insert favourite peripherals>) would be a fun toy.
The 65C02 can run at 3.3V, and the Xilinx Spartan 3E can drive 3.3V I/O. Are there any landmines I'm not seeing?
Re: game machines
sark02 wrote:
the Xilinx Spartan 3E can drive 3.3V I/O.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: game machines
Dr Jefyll wrote:
sark02 wrote:
the Xilinx Spartan 3E can drive 3.3V I/O.
I'm admittedly unfamiliar with reading DC Characteristics... but it looks like, from the Spartan 3E datasheet https://www.xilinx.com/support/document ... /ds312.pdf page 121, that for LVCMOS33:
Code: Select all
65C02 Spartan 3E LVCMOS33
Vih BE, D0, D7, RDY, SOB Vdd*0.7 = 2.31V | Voh Vcco-0.4 = 2.9V
Vih IRQB, NMIB, PHI2, RESB Vdd-0.4 = 2.9V
Vil BE, D0, D7, RDY, SOB Vdd*0.3 = 0.99V | Vol 0.4V
Vil IRQB, NMIB, PHI2, RESB Vss+0.4 = 0.4V
Does this look ok to you, too, or is there more to investigate?
Re: game machines
sark02 wrote:
Does this look ok to you, too, or is there more to investigate?
Seriously, I agree the issue of voltage levels will be OK. But I ended up browsing through that Xilinx document you linked, and there's a LOT of detail
Quote:
Unless otherwise specified in the FPGA application, the software default IOSTANDARD is LVCMOS25, SLOW slew rate, and 12 mA output drive.
Quote:
High output current drive strength and FAST output slew rates generally result in fastest I/O performance. However, these same settings generally also result in transmission line effects on the printed circuit board (PCB) for all but the shortest board traces. [...] Use the slowest slew rate and lowest output drive current that meets the performance requirements for the end application. [emphasis added]
ETA: 5 ns is what WDC lists as the slowest permissible Tr and Tf (rise time & fall time) for the w65c02s PHI2 input. AFAICT the other inputs have no maximum Tr / Tf spec.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: game machines
Dr Jefyll wrote:
It seems certain the 3E can provide appropriate I/O for your project -- which sounds pretty cool, btw
-- but you'll need to know what you want and how to ask for it.
I'll be sure to select the slow slew rate.
One other question: Would you think any of these signals will require terminating resistors (assuming 2MHz 6502 clock)? I was thinking these would be point-to-point links, and so would not require termination, but the total traces length from the FPGA to the 6502 will, I imagine, be in the order of 50-75mm.
Re: game machines
Of all the 65C02 pins, PHI2 will be the fussiest about signal integrity. I suspect that's the only one you might need to worry about -- and even that concern is probably unwarranted if you're using the slowest slew rate. But I admit I'm guessing. I didn't check what the FPGA's slowest slew rate is. (Of course if the slowest rate means Tr & Tf > 5ns then you'll have to select a rate that's faster.)
If I were in your shoes I'd simply ensure the PHI2 trace is as short as possible. Orient the 65C02 in a way that places its PHI2 pin closest to the connector from the Diligent board. And I'd recommend a PLCC package, not DIP. You might also allow some room for a terminating network (on the opposite side of the board, perhaps) but I have a hunch it'll be unnecessary.
If I were in your shoes I'd simply ensure the PHI2 trace is as short as possible. Orient the 65C02 in a way that places its PHI2 pin closest to the connector from the Diligent board. And I'd recommend a PLCC package, not DIP. You might also allow some room for a terminating network (on the opposite side of the board, perhaps) but I have a hunch it'll be unnecessary.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
Re: game machines
If I recall correctly, and all the various data sheets have a tendency to run together, the lowest current setting per output is 2mA. With a suitably configured CMOS-based system, this value may still provide a respectable slew rate.
(The FPGA IOBs control voltage and current, which relates to the slew rate by virtue of the capacitance attached to the pin. I suspect that, in most situations, the capacitance an output pin sees is predominated by the sum of the capacitance of inputs it is driving.)
(The FPGA IOBs control voltage and current, which relates to the slew rate by virtue of the capacitance attached to the pin. I suspect that, in most situations, the capacitance an output pin sees is predominated by the sum of the capacitance of inputs it is driving.)
Michael A.
Re: game machines
From the Nexsys 2 user manual:
Any red flags here?
Quote:
All signals routed from the FPGA to the FX-2 connector include 75-ohm series resistors.
Re: game machines
sark02 wrote:
Any red flags here?
MichaelM wrote:
If I recall correctly, and all the various data sheets have a tendency to run together, the lowest current setting per output is 2mA.
Pg 18 of the linked PDF wrote:
Each IOB has a slew-rate control that sets the output switching edge-rate for LVCMOS and LVTTL outputs. The SLEW attribute controls the slew rate and can either be set to SLOW (default) or FAST.
Each LVCMOS and LVTTL output additionally supports up to six different drive current strengths as shown in Table 8.
Each LVCMOS and LVTTL output additionally supports up to six different drive current strengths as shown in Table 8.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html