Jump to content
Eagle

My experiments with Atari 7800

Recommended Posts

Would it be possible to have a PokeyONE or Hokey working in conjunction with the SN76489? Or would that be too much of a strain?

Share this post


Link to post
Share on other sites
13 hours ago, RevEng said:

It's your project, so obviously do as you like. The recent sprawl over the $4xx address space for each new device is a bit concerning. Given it wouldn't need to co-exist with [email protected], is there a reason 450 couldn't be reused?

 

You're right, we may run out of free addresses in a moment. My suggestion is to use the last bit of the Covox address which is $043F. It is not being exploited. 

 

 

I am posting a bundle of all 22 songs from SN76489 downloaded from my console. Not all songs will play perfectly because they are all played on a PAL console and some songs are in NTSC. 

https://megawrzuta.pl/download/bd2efb235d1f89db5cf62ba021e0f59c.html

 

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
15 hours ago, RevEng said:

Not a problem. (it would be bit 14, as 13 was already reserved for banksets) Is this new bit for the SN76489AN, the new cart format, or both combined?

 

It's your project, so obviously do as you like. The recent sprawl over the $4xx address space for each new device is a bit concerning. Given it wouldn't need to co-exist with [email protected], is there a reason 450 couldn't be reused?

While I'm also in favor of making your own neato hardware, there's a few more points of caution here...

 

  • The $04xx region for audio expansion was inherited from the XBoard, which was connected to the full ungated address bus from Maria. Moving this into the cartridge without any sort of protection register (i.e. set some bit to enable communicating with the expansion chip) can cause a bus conflict when the 7800 is executing from its internal ROM. The SN76489 is write only, so you don't have to worry about a bus fight with this chip - but it still makes me incredibly nervous each time a new device is dropped here. I strongly recommend staying above $4000 for any new registers (as this is a write only device, you can also tuck it underneath ROM) but that's your call.
  • If you're going to source NOS components for mass production, you will run into counterfeits. Again, your call but I don't recommend the hassle.
  • The A78 header format has lost distinction between cartridge types and features. You can enable a bunch of things which conflict or don't physically exist. It's a standard now and we're stuck with it, but these same problems happened with other formats like iNES and I recommend learning from their problems and eventual solutions rather than trotting right into the same ditch.
  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, TailChao said:
  • The $04xx region for audio expansion was inherited from the XBoard, which was connected to the full ungated address bus from Maria. Moving this into the cartridge without any sort of protection register (i.e. set some bit to enable communicating with the expansion chip) can cause a bus conflict when the 7800 is executing from its internal ROM. The SN76489 is write only, so you don't have to worry about a bus fight with this chip - but it still makes me incredibly nervous each time a new device is dropped here. I strongly recommend staying above $4000 for any new registers (as this is a write only device, you can also tuck it underneath ROM) but that's your call.

The bios address-line switching scheme also makes me nervous with these endeavours, but I believe $4xx is safe. When the bios is switched in, it keeps to $Fxxx for execution (even PAL, at least until it's certain no cart is inserted) and access is limited to ZP, $2xxx, and $1Fxx. For a collision that mapped to $4xx at the cart port, we'd need the bios to access $14xx, $44xx, $54xx, $84xx, $94xx, $C4xx, or $D4xx. (ie. any x4xx address that doesn't utilise the ungated A13 line) I don't see evidence for that access, nor does it come up with a debugger check.

 

Point taken on the header and mutually incompatible options... it was that way long prior to my entry into the hobby, and as you say, we're stuck with it when it comes to the a78 header itself. Any breadcrumbs pointing to those better nes solutions? I'm always glad to learn from another scene.

 

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, RevEng said:

The bios address-line switching scheme also makes nervous with these endeavours, but I believe $4xx is safe. When the bios is switched in, it keeps to $Fxxx for execution (even PAL, at least until it's certain no cart is inserted) and access is limited to ZP, $2xxx, and $1Fxx. For a collision that mapped to $4xx at the cart port, we'd need the bios to access $14xx, $44xx, $54xx, $84xx, $94xx, $C4xx, or $D4xx. (ie. any x4xx address that doesn't utilise A13) I don't see evidence for that access, nor does it come up with a debugger check.

For the stock Atari Boot ROMs we know about - yes, it should be safe. But this is one of those niggling defensive design practices I can't ignore. Since there could be some Boot ROM variation we don't know about or someone is using a custom Boot ROM. Think about the issues you and Bob had with the Cuttle Cart and custom built-in game, it's better not to have that be your cartridge at fault (or have to diagnose it with a customer's console).

 

Basically, if you're making any new hardware - the design is fully under your control. So you can architect it to avoid potential problems rather than just the immediate ones. It's better not to worry.

 

 

Quote

Point taken on the header and mutually incompatible options... it was that way long prior to my entry into the hobby, and as you say, we're stuck with it when it comes to the a78 header itself. Any breadcrumbs pointing to those better nes solutions? I'm always glad to learn from another scene.

The ones I thought were a good compromise between flexibility and clarity are Nintendo's official headers for the Game Boy and SNES, to the point that a straight binary dump of a cartridge's ROM usually doesn't require additional tagging to know what it needs. The big structural takeaway is distinction of unique cartridge mappers, and which features can be used with each specific mapper type, rather than allowing anything to be hung off the bus.

 

Right now NES 2.0 is the de-facto ROM format for our wedge's favorite competitor, and is meant to replace the iNES format which has its own history of bogus tagging among other problems. I think it's a little overdesigned, but can understand the paranoia in trying to accommodate the broad range of cartridge designs used with the platform. It also demonstrates the extreme damage control option of drawing a hard line and restarting the format completely - but allowing for a compatibility mode for older ROMs that wouldn't need the new features anyway.

Edited by TailChao
  • Like 1

Share this post


Link to post
Share on other sites

 

1 hour ago, TailChao said:

For the stock Atari Boot ROMs we know about - yes, it should be safe. But this is one of those niggling defensive design practices I can't ignore. Since there could be some Boot ROM variation we don't know about or someone is using a custom Boot ROM. Think about the issues you and Bob had with the Cuttle Cart and custom built-in game, it's better not to have that be your cartridge at fault (or have to diagnose it with a customer's console).

For sure. I can't disagree with caution regarding new hardware and new address space usage, but I think we can characterise the risk here as "should be safe with known hardware, possible issues with future hardware, unlikely-but-possible to have issues with undiscovered gcc bioses", and let hardware devs do what they will with that info. We have a lot of carts out there with $450 pokeys in them. I don't have my finger on the pulse of cart returns, but it would be good to know if those particular carts are more likely to get returns based on console issues.

 

On alternate gcc bioses... I put together a utility cart that, among other things, calculates the 7800 bios crc. If a new bios crc is seen, it asks for a report to be returned at atariage... I haven't seen a report yet. Admittedly it's absence of evidence, rather than evidence of absence, but given the 7800's history of languishing in warehouses for some long time after gcc had stopped working with Atari, I think it's likely there may not be any unknown gcc bios variations.

 

Thanks for the nes header links! After some looking, I agree the main conceptual difference is the index of mappers, vs bitfield representation of hardware features. This mix-and-match is a mostly a problem for emulation and flash-cart devs. Game devs have the onus of picking a viable hardware combination. I can't see anyone starting a game without due diligence checking the cart hardware exists. (I do that on behalf of the 7800basic coders, as the formats I support are all viable real-hardware options) All of which I'm just voicing to characterise the issue, rather than minimise it. I'm a bit loaded to consider taking on a header replacement right now, but it would be good to hear from stakeholders on whether a mapper-targeted replacement would make their lives considerably easier.

 

At the very least, I think we could benefit from a curated mapper-based-breakdown of homebrew boards, and the expected corresponding header bits. It's sweeping the a78 dirt under the rug instead of cleaning it out entirely, but at least would give header stakeholders somewhere they can look in terms of valid options.

  • Like 1

Share this post


Link to post
Share on other sites
42 minutes ago, RevEng said:

Thanks for the nes header links! After some looking, I agree the main conceptual difference is the index of mappers, vs bitfield representation of hardware features. This mix-and-match is a mostly a problem for emulation and flash-cart devs. Game devs have the onus of picking a viable hardware combination. I can't see anyone starting a game without due diligence checking the cart hardware exists. (I do that on behalf of the 7800basic coders, as the formats I support are all viable real-hardware options) All of which I'm just voicing to characterise the issue, rather than minimise it. I'm a bit loaded to consider taking on a header replacement right now, but it would be good to hear from stakeholders on whether a mapper-targeted replacement would make their lives considerably easier.

 

At the very least, I think we could benefit from a curated mapper-based-breakdown of homebrew boards, and the expected corresponding header bits. It's sweeping the a78 dirt under the rug instead of cleaning it out entirely, but at least would give header stakeholders somewhere they can look in terms of valid options.

 

There has definitely been an explosion of audio options, and if SN76489 is already on the table then it's probably only a matter of time until somebody does AY-3-8910, and who knows what else. My suggestion is: instead of continuously adding one bit for each new audio chip, add one bit now for "new audio option" and then encode the specific new chip somewhere else. For instance, use bit 14 for "new audio option" and then when bit 14 is set, decode the actual audio chip from, say, a byte (or even 2 bytes?) at $3B. This way we can use indexing for new types without breaking compatibility with existing images.

 

Might want to do something similar for mappers. Instead of bit 12 = SOUPER, say bit 12 = "advanced mapper" with the mapper type encoded at $3D, SOUPER = 0, Banksets = 1… That will be compatible with existing R&V images as long as they have 0 at $3D.

Share this post


Link to post
Share on other sites
25 minutes ago, RevEng said:

For sure. I can't disagree with caution regarding new hardware and new address space usage, but I think we can characterise the risk here as "should be safe with known hardware, possible issues with future hardware, unlikely-but-possible to have issues with undiscovered gcc bioses", and let hardware devs do what they will with that info.

The practice I recommend for cartridge designs featuring new readable devices in the $04xx region, going forward, is to add a register above $4000 which (when set) enables communication with said chips. That's one more write for the software and a few additional gates for the hardware - and then no further responsibility outside of those.

 

Done.

 

 

25 minutes ago, RevEng said:

We have a lot of carts out there with $450 pokeys in them. I don't have my finger on the pulse of cart returns, but it would be good to know if those particular carts are more likely to get returns based on console issues.

If you want to be extra paranoid, there's an unknown number of XBoards out there and most customers won't report problems. But basically yes - I agree the risk is low, but so is awareness given the amount of times I've watched developers tread on the same rake.

 

 

25 minutes ago, RevEng said:

Thanks for the nes header links! After some looking, I agree the main conceptual difference is the index of mappers, vs bitfield representation of hardware features. This mix-and-match is a mostly a problem for emulation and flash-cart devs. Game devs have the onus of picking a viable hardware combination.

Right, especially from the emulation perspective. It's much easier just have a Cartridge -> DragonFly -> {instantiation of Pokey, YM2151, Covox, and SN76489 / DCSG} inheritance and member tree than a thousand sound chips which can be at multiple addresses.

 

If I was to implement all feasible places for a Pokey to be located given the current specification that'd be three or more at $04xx (XBoard, XM, and Cartridge) plus another at $4000 in the cartridge which can also conflict with its ROM. Yoikes :( .

 

 

25 minutes ago, RevEng said:

I can't see anyone starting a game without due diligence checking the cart hardware exists.

I mean, that's what I ended up doing - but my policy is to just design hardware and let the communities surrounding its pertinent target decide whether they want to deal with it. That's not for everyone, but a cautionary approach may be beneficial as...

 

↓↓↓↓↓

 

8 minutes ago, Pat Brady said:

There has definitely been an explosion of audio options, and if SN76489 is already on the table then it's probably only a matter of time until somebody does AY-3-8910, and who knows what else.

 

↑↑↑↑↑

 

...this has happened before, and the results are usually a bunch of sound chips or devices which are never used in manufactured and shipped game cartridges. Not to discourage making new stuff, but a good policy is to hack support for what you're using into MAME or a7800 and then formally add the hardware to the header format once it's actually used in a shipped product or there's enough traction.

 

 

25 minutes ago, RevEng said:

At the very least, I think we could benefit from a curated mapper-based-breakdown of homebrew boards, and the expected corresponding header bits. It's sweeping the a78 dirt under the rug instead of cleaning it out entirely, but at least would give header stakeholders somewhere they can look in terms of valid options.

Yep - and should probably be in another thread, to not distract attention from @Eagle and @rj1307's efforts to make the wedge dance.

  • Like 1

Share this post


Link to post
Share on other sites
22 minutes ago, TailChao said:

...this has happened before, and the results are usually a bunch of sound chips or devices which are never used in manufactured and shipped game cartridges. Not to discourage making new stuff, but a good policy is to hack support for what you're using into MAME or a7800 and then formally add the hardware to the header format once it's actually used in a shipped product or there's enough traction.

 

What has happened before?

 

The current format has 16 bits for cart types. That probably seemed like plenty back when the header was being defined, but now 13 of those bits are defined in the header doc, and 2 more (bankset and SN76489) are on the way. That means the existing scheme only has one bit remaining. Unless people stop developing new hardware, something has to give.

 

I am not proposing to define a bunch of new cart types for things that don't exist. I am proposing to create space so that new cart types can be defined as they are invented. Which can start with a couple of projects already underway but not yet finalized.

Share this post


Link to post
Share on other sites
Posted (edited)
42 minutes ago, Pat Brady said:

What has happened before?

Investment in sparsely used or never shipped hardware designs.

 

 

Quote

The current format has 16 bits for cart types. That probably seemed like plenty back when the header was being defined, but now 13 of those bits are defined in the header doc, and 2 more (bankset and SN76489) are on the way. That means the existing scheme only has one bit remaining. Unless people stop developing new hardware, something has to give.

 

I am not proposing to define a bunch of new cart types. I am proposing to create space so that new cart types can be defined as they are invented. Which can start with a couple of projects already underway but not yet finalized.

That's totally fine.

 

Edit : In the spirit of also being totally clear - I wholeheartedly agree that a pivot into a new header space for adding new cartridges as they're designed is a good move. Look at that big honkin' ACTUAL CART DATA STARTS HERE string we don't really need.

 

My points of caution are just to not allocate things on a whim, that the most popular emulator is forked from MAME so it's easy to "try before you buy", and to learn from other communities which went through the same homegrown hardware pains.

Edited by TailChao

Share this post


Link to post
Share on other sites
1 hour ago, Pat Brady said:

The current format has 16 bits for cart types. That probably seemed like plenty back when the header was being defined, but now 13 of those bits are defined in the header doc, and 2 more (bankset and SN76489) are on the way. That means the existing scheme only has one bit remaining. Unless people stop developing new hardware, something has to give.

I appreciate the suggestion, though I think we don't need to dedicate bits for what amounts to a look-elsewhere sign. We can increment the version byte in the header instead, and just define an additional word or two. (though come to think, perhaps the new word can contain mapper indexes instead, which take precedence with platforms that support the new header version, and the original format word be the nearest approximation for old emulators, if possible. But this is a conversation for another thread.)

 

Anyway, kudos to Eagle and Rafal! Thank-you for suffering though this conversation in your announcement thread. Your innovation is to blame for it all. 😝

  • Haha 1

Share this post


Link to post
Share on other sites
17 minutes ago, RevEng said:

Anyway, kudos to Eagle and Rafal! Thank-you for suffering though this conversation in your announcement thread. Your innovation is to blame for it all. 😝

Ya know Sega used two SN76489s in their System 1 arcade boards. It's only an itty-bitty teeny tiny sixteen pin chip...

 

...I bet you could stuff at least five in a 7800 cartridge.

  • Haha 1

Share this post


Link to post
Share on other sites
1 hour ago, TailChao said:

That's totally fine...

 

25 minutes ago, RevEng said:

I appreciate the suggestion, though...

 

Responded to both of these in the a78 header changes thread.

 

I agree, @rj1307's SN76489 board and @Eagle's tunes are very cool.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

 

On 3/7/2022 at 4:45 AM, SlidellMan said:

Would it be possible to have a PokeyONE or Hokey working in conjunction with the SN76489? Or would that be too much of a strain?

I see no problem.

 

For now you can use Furnace Tracker to mix SN76489 and TIA

 

https://github.com/tildearrow/furnace

 

They are planning to add POKEY soon.

 

screenshot

Edited by Eagle
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
On 3/7/2022 at 7:40 PM, Pat Brady said:

There has definitely been an explosion of audio options, and if SN76489 is already on the table then it's probably only a matter of time until somebody does AY-3-8910, and who knows what else.

https://github.com/simondotm/ym2149f

 

Quote

ym2149f

By @simondotm

Experiments with conversion of Atari ST YM2149F chip tunes to SN76489

Intro

Back in the 80's many of my friends had 16-bit machines before I did and the Atari ST was one I really wanted. Although the Amiga had more power & better audio, for some reason the Atari chip tunes always seemed really cool to me. Well, I never did get an ST, but I spent many a happy hour with my pals enjoying ST demo scene stuff.

Recently I got back into messing with chip tunes on the venerable BBC Micro just for fun with @bitshifters, when it occurred to me that maybe I could port some of my favourite tunes from the ST to the BBC Micro SN76489 sound chip.

Turns out that wasn't such a crazy idea because the Atari ST uses a PSG that's pretty similar to the Beeb.

This repo contains a script I've created to do the conversion so that you can listen to these tunes on an SN76489 sound chip as well.

 

 

Edited by Eagle
  • Like 1

Share this post


Link to post
Share on other sites
Feature YM2149 SN76489
Tone Generator Type Square Wave Square Wave
Number of Tone Generators 3 3
Dynamic Range of Tone Generators 12 bits 10 bits
Hardware Clock divider 8 16
Noise Generator Type LFSR LFSR (White or Periodic Noise )
Number of Noise Generators 1 1
Dynamic Range of Noise Generators 5 bits 10 bits
Number of Noise Mixers 3 1
Envelope Generators 1 None
Dynamic Range of Output Levels 4 bits 4 bits

 

 

6 minutes ago, Cyprian said:

that Mad Max tune rox even on SN76489

 I will try to convert some ST tunes to SN76489. Any suggestions?

 

BTW even SID songs sounds good on SN76489

 

https://negativecharge.github.io/virtualbeeb/?autoboot&disc1=https://negativecharge.github.io/files/beebsidtunes-01.ssd

 

 

more:

https://negativecharge.github.io/

 

Share this post


Link to post
Share on other sites

I'm afraid to ask but I have to just in case ;) 

It's safe to use $FFFE and $FFFF for switching banks? (of course ROM will be there)

 

Share this post


Link to post
Share on other sites
4 minutes ago, Eagle said:

It's safe to use $FFFE and $FFFF for switching banks? (of course ROM will be there)

$FFFE and $FFFF will be triggered anytime an IRQ or BRK happens.

 

My suggestion would be to avoid $FFFA..$FFFF altogether (NMI, RESET, IRQ vectors on the 6502).

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, splendidnut said:

$FFFE and $FFFF will be triggered anytime an IRQ or BRK happens.

Yes but writing will change nothing in this vector

Share this post


Link to post
Share on other sites

You'll make life easier for flash cart implementors if you allow for mirrors, so that there are fewer address lines involved in the hotspot detection. e.g. writes to Fxxx with mirrors every 8 bytes. (or 16, or 32, ..., depending on how many banks you need here) I'm not sure if address bus vs data bus hotspots have any implmentation trade-offs. Note that bank 0 would be aligned with the lower address bits being 0.

 

But otherwise I don't see anything problematic about using that range as a hotspot.

  • Thanks 1

Share this post


Link to post
Share on other sites
25 minutes ago, Eagle said:

Small update about progress :) 

 

 

20220423_071902.thumb.jpg.6ec2a07f78147400368eb6766670abe1.jpg

 

 

 

20220423_071909.thumb.jpg.f0ae9e36f7319c4b41ca4ca1e5ad47a5.jpg

Looks really interesting! Does it work already?

32k RAM, FPGA, sound chip + covox and 32 pin chip (512k, I assume) for the code...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...