Homebrew intellivision cartridges ?

[aotta]

Made a 3D printed cartridge too... models are in the github project folder:

 

I tested many bin files with different configuration map, till now RTO don't work with WSLM Baseball since it use a particular bank switching i don't know enough to emulate.

So, i consider finished this project, and looking for the next one in list.... an hard disk for the Amstrad PPC 512 

 

[+Lathe26]

On 11/27/2022 at 10:52 AM, aotta said:

Made a 3D printed cartridge too... models are in the github project folder:

 

I tested many bin files with different configuration map, till now RTO don't work with WSLM Baseball since it use a particular bank switching i don't know enough to emulate.

So, i consider finished this project, and looking for the next one in list.... an hard disk for the Amstrad PPC 512 

 

The bank switching used by WSML Baseball (and by many homebrews) is simple and documented in many places.  Without it, RTO is incomplete.

[aotta]

4 hours ago, Lathe26 said:

The bank switching used by WSML Baseball (and by many homebrews) is simple and documented in many places.  Without it, RTO is incomplete.

I know, and found some info about the bank switching last weeks, but now i'm working on others projects, i'll update the RTO Code in the future.

And, i bought an Intellivoice only a few days ago to test it!

Anyway, the source code is on github, anyone could fork it and improve it, with my plause!

[Adamj91]

Is this planned to be sold to the public? I'd be nice to finally have a good everdrive solution with SD card to the intellivision

[aotta]

1 hour ago, Adamj91 said:

Is this planned to be sold to the public? I'd be nice to finally have a good everdrive solution with SD card to the intellivision

I continued talking about the RTO Cart in the specific threads here: 

 

Anyway, i confirm i'm not interested in producing and solding the carts, but everyone is free to do it (maybe he could cash back me a little percent! ;)!

I'm supporting a few of little groups that are making small batches of carts for them, and anyone can contact me if he needs some help in assembling or programming it.

And, i'm working on a new release with some debug and a couple of new features (the reset control and the third button).

 

 

[+5-11under]

1 hour ago, aotta said:

Anyway, i confirm i'm not interested in producing and solding the carts, but everyone is free to do it (maybe he could cash back me a little percent! ;)!

And, i'm working on a new release with some debug and a couple of new features (the reset control and the third button).

I'm interested in building these. I've got a couple of Teensy 4.1 boards on the way. I'll be waiting for the new hardware updates (third button and reset), and I'll probably make a slightly different board layout.

And yes, Andrea, I'll keep your "offer" above in mind.

[aotta]

23 minutes ago, 5-11under said:

I'm interested in building these. I've got a couple of Teensy 4.1 boards on the way. I'll be waiting for the new hardware updates (third button and reset), and I'll probably make a slightly different board layout.

And yes, Andrea, I'll keep your "offer" above in mind.

I suggest you to order some 8mb psram for expanding yours teensy too, i've in mind to use it in next releases (now most of the ram is used for the ROM emulation, and some files - the Bad Apple, at most - are very large!)

[+5-11under]

15 minutes ago, aotta said:

I suggest you to order some 8mb psram for expanding yours teensy too, i've in mind to use it in next releases (now most of the ram is used for the ROM emulation, and some files - the Bad Apple, at most - are very large!)

Thanks for the suggestion. I'll order/install that separately at this point, I guess.

[Walter Ives]

On 5/8/2020 at 1:01 PM, intvnut said:

On the falling edge of BAR and ADAR, sample the address bus to the address latch.

INTAK is followed immediately by NACT-DW-DWS, so you really should latch the address on INTAK too. The INTAK fix on the original Intellivision was needed because someone forgot to do that on one of the chips; it was not meant to be a permanent feature and you should not rely on its existence. There is no INTAK fix on STIC1A boards like the INTV 1988.

 

WJI

[Walter Ives]

On 5/9/2020 at 1:56 AM, Yoruk said:

a GAL or other programmable device handles the BC1, BC2 and BDIR signals, to create the adresses latches signals and ROM chips enabling signals

T-cards used a 74LS42 BCD-Decimal decoder to decode the bus control states, then a 74LS08 Dual AND gate to combine BAR and ADAR to get the clock for the latch. It should have included INTAK in that equation, but someone decided to be clever and rely on the Master Component's INTAK fix to save a part. T-cards were never intended to end up in customer hands, so the problem was contained.

 

Beware decoder glitches. If necessary, add small capacitors to gobble them up.

 

WJI

[Walter Ives]

On 5/9/2020 at 1:56 AM, Yoruk said:

two 8 bit latches on the bus adresses (like 2*74LS373 ICs)

Use edge triggered latches (e.g.: 74LS374's) rather than transparent latches like 74LS373's to avoid the dreaded ADAR race condition.

 

WJI

[Walter Ives]

On 5/9/2020 at 1:56 AM, Yoruk said:

Didn't know if this a good start or if I'm completely wrong...?

A good start, but that Osborne schematic you're relying on is more than a bit brain-damaged. Its idea of using a bi-directional "MUX" is under-informed hand-waving, ADAR and INTAK aren't used to trigger the address latches like they should, real decoders of the day were low-going, etc., etc. This post is several years old, so you've presumably solved your problems, but later readers following in your footsteps should forget this diagram and begin by studying the T-card schematic included later in this thread instead.

 

WJI

[Walter Ives]

On 5/7/2021 at 10:10 AM, Zendocon said:

I converted it to UTF-8 for modern text viewers.

This document is a great start and an absolute boon to newcomers, but it needs some love. Here just a few suggestions to start with:

 

1.  The circuit diagrams should be changed to use the ┼ character instead of x for crossing lines.

 

2.  All references to 2764 should be to 2732.

 

3.  The "compatible RAM" referred to is the 6116.

 

4.  It should be mentioned that the 2732 4K x 8 EPROM and the 6116 2K x 8 RAM were respectively the largest available EPROM and Static RAM devices available at the time. This helps the reader understand why the designers used a RAM with only half the capacity of the EPROM.

 

5.  The mapping of the 74LS42 outputs to bus control states is incorrect. This is a documentation error that impedes understanding; the wiring shown is correct.

6.  The diagram showing the DIP switch is incorrect. It doesn't show that the signals running from the DIP switches are all connected to 1K pull-up resistors, and it shows the other side of the DIP switches being connected to 5V rather than to ground. In reality, closing a DIP switch (setting it to the ON position) grounds the corresponding signal.

 

7. The board used 1K pull-up resistors. Yikes! Since there are 32 pull-up resistors that can add up to a fairly large number of sunk milliamps, in the worst case up to 0.16 amps. The resistors should have been higher-valued. (For the LS TTL used here with each resistor pulling up a single input, R = (5-2)/0.02 = 150K, so 22K would have given plenty of noise immunity.) I mention this because anyone copying the circuit today should use higher resistor values as appropriate for the logic family they are using. 

 

The designer may have been confused by the fact that it is standard practice to use 1K resistors to pull up unused TTL inputs. If these inputs had been unused here that would have been fine. But they aren't unused: the attached switches are used to ground them.

 

WJI

[Walter Ives]

On 5/10/2020 at 11:34 AM, Yoruk said:

The "infamous book of Osborne" is a kind of resource book on the TI's CP1600

I doubt the authors of that book ever personally designed anything using the CP1600. I'd go straight to the horse's mouth: http://www.bitsavers.org/components/gi/CP1600/CP-1600_Microprocessor_Users_Manual_May75.pdf. That appears to be where the authors of the Osborne work got their information.

 

WJI

[Walter Ives]

On 5/12/2020 at 4:25 AM, decle said:

... the CP-1600 (the Intellivision's CP-1610 is a slower clocked variant) is detailed in chapter 2.

The CP1610 uses **exactly** the same die as the CP1600, the only difference is the CP1600 is packaged in a ceramic package and the CP1610 in a plastic one. GI didn't tell its full-price CP1600 customers that, of course.

 

Power is proportional to clock rate. Both versions can run at 5 MHz until they get too hot, so cool them well. If you want to try it with a plastic-packaged part, dry ice is non-conductive.

 

WJI

[Walter Ives]

On 11/11/2022 at 2:54 PM, JohnPCAE said:

You need to support ADAR in addition to BAR. Direct addressing instructions use one and indirect addressing instructions use the other.

You should really support INTAK too, especially if you want your circuit to work with STIC1A (INTV 1988) boards. See my earlier comment.

 

WJI

[Walter Ives]

On 11/11/2022 at 2:54 PM, JohnPCAE said:

n BAR and ADAR cycles, the address will not immediately be stable on the bus. When I detect them I first have to wait for about 525ns before I grab the address off the bus.

BAR, ADAR and INTAK are always followed by NACTs and have a finite hold time after the transition, so with real hardware you would be able to latch the addresses on that transition. If you were doing this in hardware with a CPU running at its designed 5 MHz clock rate you would want to use transparent latches to maximize access time, but since it's only running at a fraction of that you can use an edge triggered latch and still have plenty of access time. Indeed, if you used transparent latches ADAR cycles would suffer from a race condition unless you were running veeerrrrry slllloooowwww memories—this is why the 9600 didn't implement ADAR correctly.

 

WJI

[Walter Ives]

On 11/13/2022 at 7:22 AM, JohnPCAE said:

Oh yeah, if you're only emulating ROM then you don't need to care about DWS (as long as you're not emulating something with RAM like Chess).

The CPU puts the same data on the bus for both DW and DWS cycles. DWS was designed for memory systems with very slow write times, like magnetic cores. Remember that Honeywell wanted the CP1600 for process control, so non-volatile memory was contemplated. Such memory was no longer in common use by 1978, so Intellivision peripherals used DW and ignored DWS. You can use either in your emulation—there should be no need to use both. The CP16000 successor to the CP1600/CP1610/CP1610A dropped the DWS state to improve performance.

 

WJI

[+DZ-Jay]

18 hours ago, Walter Ives said:

I doubt the authors of that book ever personally designed anything using the CP1600. I'd go straight to the horse's mouth: http://www.bitsavers.org/components/gi/CP1600/CP-1600_Microprocessor_Users_Manual_May75.pdf. That appears to be where the authors of the Osborne work got their information.

 

WJI

404.   Is there a mirror?

[mr_me]

http://www.bitsavers.org/components/gi/CP1600/

[+Lathe26]

On 2/12/2023 at 8:17 AM, Walter Ives said:

The CPU puts the same data on the bus for both DW and DWS cycles. DWS was designed for memory systems with very slow write times, like magnetic cores. Remember that Honeywell wanted the CP1600 for process control, so non-volatile memory was contemplated. Such memory was no longer in common use by 1978, so Intellivision peripherals used DW and ignored DWS. You can use either in your emulation—there should be no need to use both. The CP16000 successor to the CP1600/CP1610/CP1610A dropped the DWS state to improve performance.

 

WJI

I had always guessed that DW and DWS existed to support to some kind of slow memory but had no clue as to what kind of memory that would be.  The connection to core memory is illuminating.

[Walter Ives]

On 2/13/2023 at 10:04 PM, Lathe26 said:

I had always guessed that DW and DWS existed to support to some kind of slow memory but had no clue as to what kind of memory that would be.  The connection to core memory is illuminating.

    Once more into the weeds, dear friends!

    Back in the day, the reason for the DWS cycle was always waved off with a vague "to accommodate memories with slow write times." Memory technology was changing rapidly, so most everyone accepted that statement as an adequate explanation and continued going about their business. However, a more precise statement would be

 

            "to accommodate memories that require a read before new data can be written."

 

    Core memories use destructive reads: you send a pair of pulses to set the polarity of a particular magnetic core to, say, zero. It takes more energy to do that if the core was one than it does if it was zero, and you detect difference in energy used. Having destroyed the original stored data with this read process you then have to write it back. For write cycles you must first clear all of the bits in the word and then, in a separate operation, write only the bits you want to set. So as far as the core array in the center of your board is concerned, every memory cycle, whether read or write, consists of a read subcycle followed by a write subcycle. You can think of such memory as requiring a three stage process:

 

     | address required | read data available | write data required |

 

    On CP1600 read cycles the data read from the core array is available by the DTB (Data To Bus) cycle and the board can write the data it retrieved back into the array during the following NACT. But on write cycles the core array isn't yet ready for the data by the DW (Data Write) cycle and wants the data to be held on the bus for a little while longer. You can see in the timing diagram below how the CP1600 does this by inserting an extra DWS bus state:

 

      Read cycle:   | BAR  | NACT | DTB  | NACT |

      Write cycle:  | BAR  | NACT | DW   | DWS  | NACT |

 

    Could one build a core board that grabbed the write data off the bus during DW and buffered it, skipping the need for DWS? Sure, but at the cost of some complexity back in a day when transistors were significantly more expensive then than they are now. Also don't forget that the BAR had already initiated the read subcycle before it knew whether it was going to be followed by a DTB or DWS.

    But this story is not unique to core memory—DRAM reads are also destructive, and the read data has to be written back there too. The design of the first commercially successful DRAM was done by Intel at the instigation of Honeywell, a manufacturer of core memory systems and not entirely coincidentally the same company that instigated the development of the CP1600. After some drama, Intel created the 1103 1K x 1 DRAM. Like the core memory described above, every memory cycle of that particular device did a read of the memory array followed by a write. The read data comes out of the device first, the write data is required later. For the CP1600, these times line up respectively with the DTB/DW and DWS cycles.

    In thinking about all this, it helps to remember that the CP1600 design clock rate was 5 MHz, meaning that every bus state was only 400 ns long. The memory systems, whether core or DRAM, were on separate boards. So those memory accesses were not as pokey as you are used to considering them.

    The fact that the first DRAMs used timing similar to that of core memories was not a coincidence because, surprise of surprises, their first use was to make less expensive expansion memory subsystems for large computers that had been designed to use cores. By less expensive I mean that at a time when IBM had a market selling memory for $1.2 million per megabyte, Intel sold its first compatible memory systems at the bargain basement price of three quarters of a million dollars per megabyte. That's for a system with ten thousand 18-pin packages (don't forget the error detection/correction bits!), denominated in 1972 dollars. Needless to say, IBM was not exactly overjoyed.

    Back in those days mainframe memory came in its own cabinets, separate from the CPU.

    To put the timing in context: Intel began shipping the 1103 in 1971 and it took several years to get the reliability high enough to satisfy the non-early-adopter types. At the other extreme, universities with PDP-10's, technophiles and limited budgets loved them. The CP1600 was conceived during this timeframe and was being designed to handle these latest 1Kx8 DRAMs.

    Write cycles for static RAMs and later DRAM designs did not require the preparatory read, and by the time the Intellivision was being designed the DWS cycle was a historical anachronism.

    Did anybody read this far?

 

    WJI

[+DZ-Jay]

8 hours ago, Walter Ives said:

    Once more into the weeds, dear friends!

    Back in the day, the reason for the DWS cycle was always waved off with a vague "to accommodate memories with slow write times." Memory technology was changing rapidly, so most everyone accepted that statement as an adequate explanation and continued going about their business. However, a more precise statement would be

 

            "to accommodate memories that require a read before new data can be written."

 

    Core memories use destructive reads: you send a pair of pulses to set the polarity of a particular magnetic core to, say, zero. It takes more energy to do that if the core was one than it does if it was zero, and you detect difference in energy used. Having destroyed the original stored data with this read process you then have to write it back. For write cycles you must first clear all of the bits in the word and then, in a separate operation, write only the bits you want to set. So as far as the core array in the center of your board is concerned, every memory cycle, whether read or write, consists of a read subcycle followed by a write subcycle. You can think of such memory as requiring a three stage process:

 

     | address required | read data available | write data required |

 

    On CP1600 read cycles the data read from the core array is available by the DTB (Data To Bus) cycle and the board can write the data it retrieved back into the array during the following NACT. But on write cycles the core array isn't yet ready for the data by the DW (Data Write) cycle and wants the data to be held on the bus for a little while longer. You can see in the timing diagram below how the CP1600 does this by inserting an extra DWS bus state:

 

      Read cycle:   | BAR  | NACT | DTB  | NACT |

      Write cycle:  | BAR  | NACT | DW   | DWS  | NACT |

 

    Could one build a core board that grabbed the write data off the bus during DW and buffered it, skipping the need for DWS? Sure, but at the cost of some complexity back in a day when transistors were significantly more expensive then than they are now. Also don't forget that the BAR had already initiated the read subcycle before it knew whether it was going to be followed by a DTB or DWS.

    But this story is not unique to core memory—DRAM reads are also destructive, and the read data has to be written back there too. The design of the first commercially successful DRAM was done by Intel at the instigation of Honeywell, a manufacturer of core memory systems and not entirely coincidentally the same company that instigated the development of the CP1600. After some drama, Intel created the 1103 1K x 1 DRAM. Like the core memory described above, every memory cycle of that particular device did a read of the memory array followed by a write. The read data comes out of the device first, the write data is required later. For the CP1600, these times line up respectively with the DTB/DW and DWS cycles.

    In thinking about all this, it helps to remember that the CP1600 design clock rate was 5 MHz, meaning that every bus state was only 400 ns long. The memory systems, whether core or DRAM, were on separate boards. So those memory accesses were not as pokey as you are used to considering them.

    The fact that the first DRAMs used timing similar to that of core memories was not a coincidence because, surprise of surprises, their first use was to make less expensive expansion memory subsystems for large computers that had been designed to use cores. By less expensive I mean that at a time when IBM had a market selling memory for $1.2 million per megabyte, Intel sold its first compatible memory systems at the bargain basement price of three quarters of a million dollars per megabyte. That's for a system with ten thousand 18-pin packages (don't forget the error detection/correction bits!), denominated in 1972 dollars. Needless to say, IBM was not exactly overjoyed.

    Back in those days mainframe memory came in its own cabinets, separate from the CPU.

    To put the timing in context: Intel began shipping the 1103 in 1971 and it took several years to get the reliability high enough to satisfy the non-early-adopter types. At the other extreme, universities with PDP-10's, technophiles and limited budgets loved them. The CP1600 was conceived during this timeframe and was being designed to handle these latest 1Kx8 DRAMs.

    Write cycles for static RAMs and later DRAM designs did not require the preparatory read, and by the time the Intellivision was being designed the DWS cycle was a historical anachronism.

    Did anybody read this far?

 

    WJI

I did.  Thanks for sharing.

[+Lathe26]

18 hours ago, Walter Ives said:

    Did anybody read this far?

 

    WJI

 

When I read this far, I see this

 

When I read this close, I see this

[overCLK]

Hello there!

Long story short: Got myself a french intellivision (with the SECAM mod) and modded it for RGB output, but since I only have a game (Astrosmash), was interested into trying to make my own homebrew cartridge. This is how I ended up reading this interesting thread and even tho I think I understand the idea, I'm a bit stuck now with my experiment, so coming here to see if you guys with your expertice and knowledge about the hardware can shed some light on my path as newbie in the intellivision field.

 

Don't know if it would be better to open a different thread but since this one is about homebrew cartridges, maybe it's more useful to have all the information together.

 

So basically my attempt is based on a Xilinx CPLD xc95144xl, which is 5V tolerant and I think it should be enough to decode the signals, latch the address requested by the CPU and do the needed decoding of the address to drive a ROM/RAM,... So far I have a prototype board with the CPLD and two 8 bit ROMs working in parallel to provide the cartridge content.

I tried to do combinational decoding of BDIR, BC1 and BC2 but found out on the analyzer output that sometimes I got some spurious ADAR phases (very short ones), seems that because there is a little offset between BC1 and BC2 changes (don't know if this could be some defect of my intellivision) and this leads to a detection of ADAR by the CPLD (attaching a capture of the oscilloscope just for sharing). I was able to remove that by using some sort of debouncing approach (sampling with a fast clock in the CPLD and discarding short pulses on ADAR), and now I'm trying to validate address latching. I'm doing it on the falling edge of BAR and ADAR but I'm not sure at all of the results. I connected the analyzer to the address bus and sampled the lower address bits on the falling edge of my "latch clock" what is (ADAR or BAR) getting results that don't match what I expect comparing it with jzintv debug. But maybe (most likely) I'm missing something here. 

So my first reads of the address bus are (I have only the 7 lower bits):

0000

0001

0002

0026

0027

0028

0029

002A

 

But my understanding is that since the reset vector is in $1000 and this is the dissassembly of the EXEC there:

I should expect rather something like:

0000

0001

0002

0029

...

or am I missing something? Is there any other reason why I could have those reads? 

 

This is just the offset between my BC1 (blue) and BC2 (yellow) what led to that short ADAR spike (purple) I was commented before

Cheers!

Manuel