Jump to content

bizarrostormy

+AtariAge Subscriber
  • Content Count

    160
  • Joined

  • Last visited

Community Reputation

234 Excellent

1 Follower

About bizarrostormy

  • Rank
    Chopper Commander

Profile Information

  • Location
    Madison, WI, USA

Recent Profile Visitors

3,532 profile views
  1. I believe so. The pinout doesn’t show any line to indicate valid data, and MARIA doesn’t know which addresses are RAM and which are ROM. I think it just assumes that DLs and the DLL will be available 2 cycles later, and graphics data by 3. Conversely DLs and the DLL are not really required to be in RAM, they just must return in 2 cycles. In 1983 that effectively meant RAM, nowadays maybe not. I haven’t tested any of this though. It’s unfortunate for 7ix, where most of the graphics are in RAM. But I think I’ll be okay on DMA time anyway.
  2. Thanks for the tip! I’ll check it out next time I’m up that way.
  3. BUMP. Did anybody, in the past decade, ever figure this out? gdement referenced the GCC spec: “Regular DMA is initiated on the leading edge of HBlank.” He took that to mean MARIA cycle 34. But the screen layout diagram in that document shows another HBlank, starting at cycle 440 of the previous line. I suspect that is when DMA starts. I think GroovyBee’s numbers are also off, because only shutdown can happen in the 27 cycles of (right side) border. If you have 12 cycles of startup starting at 440, that leaves 413 cycles until abort. Thanks to RevEng’s clarifications in the Updated Software Guide, we now understand that at least some of the variance in startup and shutdown time is based on whether SALLY is accessing the bus and if so, whether that access is throttled for TIA or RIOT. It’s tough to do something interesting without accessing the bus, and very difficult to control which MARIA cycle it lands on, but it is feasible to prevent TIA/RIOT accesses during DMA, so we can save a couple of cycles there. So my read is that we reliably have 413 cycles per line for reading headers, maps, and graphics, but if we can avoid TIA and RIOT, that becomes 415.
  4. I’m not totally versed on this stuff, but last I read, XM would provide 128k RAM, HSC, POKEY, YM, an SIO port, a keyboard port, and ability to play cartridge-only games (but not a way to play ROM files from the internet, aside from inserting one of the carts that can do so). Decked-out Concerto provides 16k RAM, HSC, and POKEY. Decked-out Dragonfly will provide 16k RAM, POKEY, and YM. The other differences are that Dragonfly has its own power supply and does game selection on cart instead of via menu. Different users might consider these advantages or disadvantages. To me, Dragonfly looks much closer to Concerto than to XM. It will be nice to have a choice, should Concerto and Dragonfly both become available. I personally prefer the feature set and design of Concerto.
  5. This may be a mistake, but I’ll bite. Which of those terms and phrases — spinoff, repackage jobber, spiritual replacement, intermediary with minimal technical advances — do you think applies to the 7800, and from what earlier system?
  6. Oh hi. The “someone” Synthpopalooza mentioned is me. I have several different tables, mostly with just intonation in various keys, and the 2 different clocks. Synthpopalooza didn’t like the value I had for B flat in the C major table, so I made another one using 16/9 instead of 9/5 for the minor 7th. For each key, the tonic is on dark green background, the major third, fourth, and fifth are on medium green, and the other notes in the scale are on light green. The text is colored depending on how out of tune that setting is, orange for flat and purple for sharp, lighter text indicating further out of tune. To be clear, I did not start with any particular value for A4. Instead I picked (for each table) an AUDF setting that works well for that key. Everything else is a formula. The table called “Equal Temperament” is very close to the standard table as in the POKEY doc and COMPUTE!. This table is based on A4=440, which POKEY 8-bit can’t do especially well. I added two alternative equal temperament tables that are based on notes POKEY 8-bit can do. But frequency division works well with just intonation. I intend to continue adding more keys and otherwise refining it. Here is the link. And here is the thread in the 7800 forum about it. EDIT: the non-$A distortions are somewhat WIP. My $Cx values seem okay but the $2x are not quite right. EDIT: Oh I see Synthpopalooza already linked that to a different thread in this forum. But it seemed relevant to your comment here.
  7. Thanks for the explanation. In my case, the argument is already a quoted string, not a label, so = is correct and my comment about setstr was superfluous.
  8. Ah. I was not aware of the 2.20.14 release. 2.20.13 does not support 'setstr'. TBH I’m not clear on the difference between 'set' and 'setstr'. The = seems to work fine in this case.
  9. I often want to check the top nybble, and there might be uses (bankswitching?) to check other ranges. This version can check any number of bits on either the high side or the low side. This also uses no global symbols. The trick to getting rid of them was to assign a local label from the parameter in the leaf macro. mac samebits ; {numbits, addr1, addr2, mask, side} list localoff .numbits = {1} .addr1 = {2} .addr2 = {3} .mask = {4} .side = {5} ; current dasm doesn't have setstr .addr1masked = .addr1 & .mask .addr2masked = .addr2 & .mask if .addr1masked == .addr2masked .SAMEBITS_EXISTS ; defined if non-masked bits are equal endif ifnconst .SAMEBITS_EXISTS echo "ERROR: ", .side, " ", .numbits, "bits difference (", .addr1, ",", .addr2, ")" err endif endm mac samelow ; {numbits, addr1, addr2} samebits {1}, {2}, {3}, [1<<[{1}]]-1 & $FFFF, "low" endm mac samehigh ; {numbits, addr1, addr2} samebits {1}, {2}, {3}, ~[[1<<[16-[{1}]]]-1] & $FFFF, "high" endm mac prevsamelowas ; {numbits, addr} samelow [{1}], .-1, [{2}] endm mac nextsamelowas ; {numbits, addr} samelow [{1}], ., [{2}] endm mac prevsamehighas ; {numbits, addr} samehigh [{1}], .-1, [{2}] endm mac nextsamehighas ; {numbits, addr} samehigh [{1}], ., [{2}] endm mac prevsamehigh8as ; {addr} ; deprecated: use prevsamehighas instead prevsamehighas 8, [{1}] endm mac nextsamehigh8as ; {addr} ; deprecated: use nextsamehighas instead nextsamehighas 8, [{1}] endm
  10. That is pretty much how it works. Anyway, I have gotten back into this project. There is much work to do, and I probably won’t drop another binary for a while, but it feels good to be making progress again.
  11. Received my VecMulti a while ago. It works great. Trans-Atlantic shipping was shockingly fast.
  12. I bought a few games and a book from King_Salamon. Totally smooth transaction with good communication. I will be happy to deal with him again.
  13. I bought a couple of games from Curious Sofa. Very smooth transaction with good communication. I will be happy to deal with him again.
  14. I join the chorus of folks pulling for you.
  15. The Software Guide says the encryption area is from FF7A to FFF9. The Game Standards and Procedures document says the encryption key occupies FF80 to FFF7, with FFF8 and FFF9 serving other purposes. From inspection of Bruce Tomlin’s sign7800.c (which seems to work correctly) I believe FF80 to FFF7 is correct. This suggests cartridges can use the 6 bytes from FF7A to FF7F. I tested that with no problems, and have edited the document accordingly. This might be an appropriate place to describe the contents of FFF8 and FFF9, but I have not yet done so.
×
×
  • Create New...