14 replies to this topic

[kenfused]

Has anyone been able to get the Atari Vox to speak on a 7800 in 7800 mode? So far all I have got is gibberish. I am correct in assuming that during the VB, nothing should be interrupting the processor and that there is no RAM refresh since the thing is using static RAM. I realize we are running and a faster clock rate 1.79 vs. 1.19 and that there is the condition of the CPU slowing to access the joystick registers though when outputting data (which maybe costs the equivalent of a cycle or two in 1.79 MHZ?).


Thanks,
--Ken

[gdement]

You maybe have already seen this, but somebody was having similar troubles on an 800:

http://www.atariage....showtopic=66856

I don't have any experience with the SpeakJet or serial I/O though. I don't think anything would interrupt the CPU during vblank, at least nothing I can think of. Maybe it's just a timing issue like you mentioned.

[kenfused]

Well, it isn't speaking giberish anymore but something still seems wrong. I have it say "hello" a few times in a row. Sometimes it sounds more like yello or other sounds than hello (just the initial syllable, the ello sounds consistant). I would think if there was a serial communications problem, the rest of the word would get messed from time to time. A worse problem is, I don't think I am going to integrate this into anything unless I can some how interleave the waits for sending data with updating the graphics which will probably not be fun. This just seems like a naturnal for a game I am working on (people can probably guess) to be able to optionally use.

--Ken

[kenfused]

Well, I think I have all of the technical problems worked out. Here is an attempt to add a couple AtariVox sounds to Qbert. Added a sound when you fall and when you get hit with a ball. I am finding it very hard to get sounds to sound like what I want.
Note: This version may or may not work without and AtariVox currently and will be missing some sounds if it does work. Also ignore the date that is displayed on the title screen.

Attached Files

•  qbert.zip   17.36K   128 downloads

[Schmutzpuppe]

Cool, unfortunately I don't have an Atari Vox but maybe it's worth a buy if more games would support it.
Could you upload a small sample of how it sounds?

[Richard H.]

Quote

I am finding it very hard to get sounds to sound like what I want.

You need the PC interface, it's MUCH easier to work on sounds / speech with it

[~llama]

How does the AtariVox work on the 7800 in 7800 mode in terms of using it for data storage? I may be needing it for a little project I'm working on... see my blog here for a little info but in order to proceed I need to know whether or not the AtariVox is useful for saving data from a 7800 in 7800 mode. Has anyone here tried using it for that purpose yet?

[Richard H.]

Let me send you a free MemCard to experiment with

(PM me your address)

[Bruce Tomlin]

...and I got mine in the mail today. It looks pretty simple, just a standard I2C interface with the A0,A1,A2 select lines of the chip grounded. I think the main problem is going to be how the 16K of space gets divided up. I'm really all for a directory in the first block that tells how many blocks in the chip (unfortunately you can't auto-detect the chip size vs other I2C EEPROMs, so it might need a destructive test if you want to know how big it is when you format) with an index of game ID codes and a FAT-style next block number. A simple format routine could be included in every game that needs it.

Assigning a single 64 or 128 byte block per game might work fine for 2600 games, but the 7800 is going to need a real index. Just one RPG could need a couple hundred bytes per save, and multiple save slots.

Hmm, let's see... here's the pinout:

1
2
3 (left) SCL
4 (right) SDA
5
6
7 +5
8 GND A0 A1 A2 WP
9

EDIT: Hmm, now all we need is an I2C to AT keyboard interface. Looks like I'm not the first guy to realize that's a useful thing: http://www.semicondu...notes/AN434.pdf

Edited by Bruce Tomlin, Tue Sep 6, 2005 10:17 PM.

[Richard H.]

Quote

now all we need is an I2C to AT keyboard interface

I'll make them if you think there's enough demand ?

Quote

Assigning a single 64 or 128 byte block per game might work fine for 2600 games, but the 7800 is going to need a real index. Just one RPG could need a couple hundred bytes per save, and multiple save slots.

Yes, it needs an all new format for the 7800.

I could do a 7800 version of the Memory Allocation Table with bigger blocks.

[Bruce Tomlin]

Richard H., on Wed Sep 7, 2005 6:55 AM, said:

Quote

now all we need is an I2C to AT keyboard interface

I'll make them if you think there's enough demand ?

I don't think there will be any demand until there's something that uses it. And what I linked to really isn't good enough anyhow. It would be nice to have make/break codes instead of fully converting everything to ASCII, and it might also be nice to support the "official" 7800 keyboard protocol via an option switch as well. You better hold off on this.

Quote

Quote

Assigning a single 64 or 128 byte block per game might work fine for 2600 games, but the 7800 is going to need a real index. Just one RPG could need a couple hundred bytes per save, and multiple save slots.

Yes, it needs an all new format for the 7800.

I could do a 7800 version of the Memory Allocation Table with bigger blocks.

That's not good enough. The "one fixed block per game" idea works fine when all you're doing is saving high scores, or even game states in a system with a mere 128 bytes of RAM, but for the 7800 there needs to be some way to have more than one block per save, and more than one save per game. It would be good if it could work more like a Playstation 1 memory card.

Something like breaking it up in to blocks of some fixed size in the range of 128 to 1024 bytes, with the first block(s) containing the index. The first block will contain the total number of blocks, the number of blocks used by the index, and the index itself. Each index entry would have a game ID (maybe 1-3 bytes) and a next block number. 2600 save space could even be pre-reserved as its own save file if compatibility was absolutely necessary.

Edited by Bruce Tomlin, Mon Sep 12, 2005 12:02 PM.

[Richard H.]

Quote

now all we need is an I2C to AT keyboard interface

PS-2 keyboards have 4 connections -

Clock
Data
+5V
GND

Surely, it could be connected straight onto the port and the code do the rest ?

(I was going to use a PIC to decode, and spit serial ASCII back to the console)

Quote

but for the 7800 there needs to be some way to have more than one block per save, and more than one save per game

Yes

I say forget 2600 backward compatibility and devise an all new file structure for the 7800.

You're obviously better than I at working out such a scheme.

Do you want to lay some thing out + perhaps discuss it on the 7800 forum ?

[supercat]

Richard H., on Mon Sep 12, 2005 2:13 PM, said:

Yes

I say forget 2600 backward compatibility and devise an all new file structure for the 7800.

That would seem rather annoying, since it would require people to use their Atarivox with either the 2600 or 7800, and not both.

I don't know, though, whether anyone is already using the 'file structure' part of things; the one change I would make there (for both systems) would be to, for each block, have a byte which identifies what application created that block. Applications could then use their own methods for handling larger saves, multiple saves per application, etc.

Another thing I'd like to see--I forget whether you already provide for this or not--would be an area of 4K or 8K or so which the current running application could use as it sees fit, but which would not be expected to be preserved when going from one application to another. This would allow games whose "working set" is larger than available memory, provided that the data need not be accessed too quickly. A room-based dungeon game, for example, could keep the state of the current dungeon in EEPROM while the current room is kept in RAM. Going room to room would save the present room and load the new one.

[Bruce Tomlin]

supercat, on Mon Sep 12, 2005 5:55 PM, said:

Richard H., on Mon Sep 12, 2005 2:13 PM, said:

I say forget 2600 backward compatibility and devise an all new file structure for the 7800.

That would seem rather annoying, since it would require people to use their Atarivox with either the 2600 or 7800, and not both.

Well, honestly, I really don't care about the voice part, just the EEPROM part. Without the voice, you can just use a different module for each. The 7800 can look for a magic ID number at the start of the module put there during "formatting", and could complain if it's not there.

Quote

Another thing I'd like to see--I forget whether you already provide for this or not--would be an area of 4K or 8K or so which the current running application could use as it sees fit, but which would not be expected to be preserved when going from one application to another.  This would allow games whose "working set" is larger than available memory, provided that the data need not be accessed too quickly.  A room-based dungeon game, for example, could keep the state of the current dungeon in EEPROM while the current room is kept in RAM.  Going room to room would save the present room and load the new one.

That's pretty unlikely on the 7800, since room states can be pretty compact if you do things right, and you can always add RAM to the cartridge anyhow. The only need for the EEPROM is long term storage between sessions, and being able to go back to an earlier save if you screw up.

[Richard H.]

Quote

it would require people to use their Atarivox with either the 2600 or 7800

I was talking about the MemCard, and it being supplied with the homebrew 7800 game cart. I think they're cheap enough to make this viable.

Quote

Another thing I'd like to see would be an area of 4K or 8K or so which the current running application could use as it sees fit

That's what the other 16K is for ($4000 - $7FFF)

Edited by Richard H., Tue Sep 13, 2005 9:32 AM.