Posts: 3
Joined: Tue Jul 26, 2016 7:58 pm

Mattel Intellivision Keyboard Component

I'm actively working on MAME again after a short decade or so break :) I've catching up on all the C++ enhancements that have been made since I worked on it last.

I'm trying to finish off the Mattel Intellivision Keyboard Component Driver (intvkbd). I've been updating the CRT5027 CRT Controller device to overlay high-resolution text properly over the Intellivision display. I have put one of my reverse-engineering tools online, a cartridge image which loads a 6502 monitor program into the actual hardware via the Intellivision cartridge slot:

I have a lot of recovered data from the tape drive. For step one - I'll be taking some recovered data, the "Family Budgeting" BASIC program, and getting it to load into the emulator. I actually have this working in an ancient version of MESS (2003?), so it's just a matter of porting it over - however, the tape format I used is not sufficiently general to support the other tapes. I'll post some screen shots when I get this working.

I need to define a better tape format, probably building from the existing cassette support in MESS. The tape drive is a fancy 4-track device, with 2 audio and 2 data channels, one of each are read only, the other 2 being read/write. Hopefully I'll be able to verify the validity of the other existing tape dumps. The BASIC programs use only a subset of the tape drive, and none of the Intellivision graphics and sound. But the more sophisticated tapes use the full capabilities of the Intellivision plus interaction via the tape drive.

As a last step, there is a microphone input which can be used to record audio onto the audio track. As I understand it, MAME has no existing support for audio input, so I guess I'll save support for that until the end.

Posts: 27
Joined: Fri Nov 14, 2014 4:27 pm
Contact: Website

Re: Mattel Intellivision Keyboard Component

Sounds awesome!

Posts: 3
Joined: Tue Jul 26, 2016 7:58 pm

Re: Mattel Intellivision Keyboard Component

2 years later...back at it again! Making great progress, having a few questions.

My github is here:

Several tapes have been completely decoded, so now I'm working on MAME's implementation of the tape drive.

I figured out that the standard cassette_image_device wasn't going to cut it. Too many differences between that and the intvkbd drive.
The cassette_image code, however, seems fine to use. This makes sense as the media should be almost identical to standard cassette media.

I'm implementing my own drive in machine/intvkbd_tapedrive.* using my own cassette_image_device-like class.

I've got the tape images loading, and the drive motor control working.

My question is about "plumbing" - aka how to setup the update() calls so that everything happens more or less like the real thing.

When reading a tape, the drive can provide interrupts at the bit rate of nominally 3000bps.
When playing audio, (which it can do simultaneously from a different track,) it will provide audio data as needed. My current tape format has 48000Hz audio just to make things easy for now.

When I implemented this in my personal version of MESS back in 2002, I set up a timer at exactly 3000Hz, and had a tape format with the bits already decoded. So, I stepped through bit by bit and everything worked great. However, this seems a bit like cheating, because the data on the tape is Biphase-Mark encoded, and not necessarily at exactly 3000bps. I feel like I need to be processing the raw tape image and still supporting audio playback as needed. At any rate, lets call this option A)

So, I have 2 alternative ideas.

If you look at the TRS-80 driver, it gets called every 11Khz even though the max bit rate is 1500baud. It processes a bit of the tape each time, looking for a "end of bit" and then processes that bit. This causes a little bit of random latency per bit, but as long as it's not too much, things should work fine. So, in my case I would use something like 24000Hz and do the same processing on my 3000bps data stream. Call this alternative B)

I just came up with C). Use a timer on the fly to trigger a callback whenever you know there is the next "event" coming from the tape. That way everything happens at exactly the right time. This seems a little complex to set up, but I feel like the accuracy would be great. I only wish there was another driver with this kind of example to follow - I haven't been able to find one. This makes me think I am missing something fundamental.

At any rate, I will probably try to get option B) going, and see how it goes. I can at least see how that would work all the way. :) If any other MAME developers have a recommendation, I'd love to hear it.


Posts: 1
Joined: Sat Oct 06, 2018 12:16 pm
Contact: Website

Re: Mattel Intellivision Keyboard Component

Hey Frank,

Are you looking for any contributors to this project?

Let me know as l would try contribute when I have some free time.


Return to “Work In Progress (WIP)”