Jump to content

Photo

IntyBASIC compiler v1.2.9: The good things are now better!

Intellivision IntyBASIC

265 replies to this topic

#51 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Thu Oct 22, 2015 8:43 PM

2 things tonight, I'm gonna make 2 posts in case people start quoting and it gets confusing.

 

First: Sr. nanochess, I have uncovered a bit of a problem with IntyBASIC and memory mapping. Typically, a lot of us are using hacks like ASM ORG $C100, to get a lot more ROM space. Well... it turns out that at least *I* have never actually tested this with the ECS turned on in jzintv. So I only discovered this when using a REAL ECS for my games.

 

The ECS maps its ROMs at $E000-$EFFF, and that breaks any program that maps into that space (which my bigger games do). Joe Z posted a fix for this a long while back, which completely disables the ECS:

  ORG     $4800
        ; Disable ECS ROMs so that they don't conflict with us
        MVII    #$2A5F, R0
        MVO     R0,     $2FFF
        MVII    #$7A5F, R0
        MVO     R0,     $7FFF
        MVII    #$EA5F, R0
        MVO     R0,     $EFFF
        B       $1041           ; resume boot

In his words, "You should be able to blindly drop that in the epilogue at the end and get most of the benefit."

 

Of course, some people will want to use the ECS - so maybe have a BASIC command, ECS ON/OFF? Or maybe it's off by default (most games won't use it), and you have to specify ECS ON when you want to use it. And then we'll have to somehow document it so that people don't run into the $EXXX range when they want to use the ECS.

 

Let me know if I'm not making sense. I think a few people's games are going to break if they turn on the ECS in jzintv. Mine sure did :D



#52 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Thu Oct 22, 2015 8:52 PM

Second:

 

The code for music synth scanning that intvnut posted above works flawlessly. Aaaaaaaand, I'm happy to announce that the LTO Flash! works with a "fully extended" system - console, ECS, Intellivoice, Music Synthesizer, and cart. Plus a ROM that takes advantage of all of the above.

 

I'll post something eventually, once I get it a bit less hacky. The ROM works just fine in jzintv with --ecs=1 and -v1. I figure there might be 5 people on the planet right now that can experience the full thing in all its glory. But that's gonna change soon!

 

Ironically, the 49-key keyboard doesn't have enough keys. Who would have thought?



#53 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Fri Oct 23, 2015 1:25 AM

I think a few people's games are going to break if they turn on the ECS in jzintv. Mine sure did :D


If you use "cont3" or "cont4" or have a "sound 5,0,0" in your code then the ECS ROMs are automagically mapped out.

#54 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Oct 23, 2015 6:58 AM

If you use "cont3" or "cont4" or have a "sound 5,0,0" in your code then the ECS ROMs are automagically mapped out.

 

Counter-intuitive, but makes sense. The problem is then for games that don't use them - or people who don't know about this "trick". The code that maps them out should be included by default, really. How many people are ever going to use the ECS ROMs in their games?



#55 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,978 posts
  • Coding something good
  • Location:Mexico City

Posted Fri Oct 23, 2015 1:53 PM

 

Counter-intuitive, but makes sense. The problem is then for games that don't use them - or people who don't know about this "trick". The code that maps them out should be included by default, really. How many people are ever going to use the ECS ROMs in their games?

 

If you stick to the standard Intellivision memory map of $5000-$6fff, $d000-$dfff and $f000-$ffff you should not find any trouble ;)

 

The ECS code is only required when you expand over other memory areas.



#56 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Fri Oct 23, 2015 5:36 PM

 

If you stick to the standard Intellivision memory map of $5000-$6fff, $d000-$dfff and $f000-$ffff you should not find any trouble ;)

 

The ECS code is only required when you expand over other memory areas.

 

Well sure, but why give up 16K for nothing? :P



#57 Kiwi OFFLINE  

Kiwi

    Stargunner

  • 1,411 posts

Posted Fri Oct 23, 2015 5:41 PM

You could use a bankswitching cartridge for the ECS if you need more than 16K.



#58 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,969 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Oct 24, 2015 5:17 AM

You could use a bankswitching cartridge for the ECS if you need more than 16K.

 

Ugh, bank-switching is not necessary.  Most PCB boards (including the upcoming flash-carts) contain built-in RAM, and for ROMs, the emulator supports it.

 

I'm with freewheel on this:  just switch the ECS to an unused bank and get it out of the way using Joe Z.'s hack.  There is no need for the ECS EXEC at all, and this does not affect the extra PSG.


Edited by DZ-Jay, Sat Oct 24, 2015 5:17 AM.


#59 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 9:38 AM

*grumble grumble* stupid PC keyboard ghosting.

 

The Intellivision can register 49 discrete keypresses. My PC keyboard manages far fewer - sometimes as few as 2 depending on the exact keys I'm pressing. The Intellivision, with ECS attached, has 6 distinct sound channels. I need to be able to distinguish 6 discrete keys being pressed.

 

IT'S IMPOSSIBLE TO PROPERLY TEST THIS IN EMULATION.

 

*ahem*

 

Although... I thought modern PC keyboards could register a lot more discrete keys pressed at once. Is this a jzintv thing?

 

 

 

Regardless: Thanks be to the man who got me a way to test on real hardware! I'm giggling like a schoolgirl at the moment. This is (so far) a lot easier than I thought.



#60 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 9:58 AM

Feature request: SOUND index,value,vol.

 

The same way SPRITE index,x,y,f works.

 

:D

 

And in a perfect world, SOUND 0-5 would represent all 6 possible sound channels, 6 and 7 the envelopes, 8 and 9 the noise channels. Or something to that effect. This of course will break SOUND for a lot of people. Hmmm....I guess that's easily done via lookup table to not break things for everyone else :)

 

But I'd LOOOOOVE SOUND index!



#61 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Oct 24, 2015 10:18 AM

Its already in there!

SOUND 0,[VALUE 12 bits],[VOL 0-15] Channel A
SOUND 1,[VALUE 12 bits],[VOL 0-15] Channel B
SOUND 2,[VALUE 12 bits],[VOL 0-15] Channel C
SOUND 3,[VALUE 16 bits],[TYPE 0-15] Envelope (frequency/shape)
SOUND 4,[NOISE 6 bits],[MIX] Noise and mix register ($38 value by default)

Only for the secondary PSG in ECS add-on module
SOUND 5,[VALUE 12 bits],[VOL 0-15] Channel A
SOUND 6,[VALUE 12 bits],[VOL 0-15] Channel B
SOUND 7,[VALUE 12 bits],[VOL 0-15] Channel C
SOUND 8,[VALUE 16 bits],[TYPE 0-15] Envelope (frequency/shape)
SOUND 9,[NOISE 6 bits],[MIX] Noise and mix register ($38 value by default)


#62 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,978 posts
  • Coding something good
  • Location:Mexico City

Posted Sat Oct 24, 2015 10:27 AM

Feature request: SOUND index,value,vol.

 

The same way SPRITE index,x,y,f works.

 

:D

 

And in a perfect world, SOUND 0-5 would represent all 6 possible sound channels, 6 and 7 the envelopes, 8 and 9 the noise channels. Or something to that effect. This of course will break SOUND for a lot of people. Hmmm....I guess that's easily done via lookup table to not break things for everyone else :)

 

But I'd LOOOOOVE SOUND index!

 

Oh yes! SOUND index still it's constant. I've took note. :)



#63 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 12:42 PM

Its already in there!
 

Not as an index :)



#64 GroovyBee OFFLINE  

GroovyBee

    Games Developer

  • 9,736 posts
  • Busy bee!
  • Location:North, England

Posted Sat Oct 24, 2015 12:57 PM

To me, using a variable as the channel isn't much use unless you are making a prioritising sound FX engine.

#65 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,827 posts
  • Location:@R6 (top of stack)

Posted Sat Oct 24, 2015 4:36 PM

To me, using a variable as the channel isn't much use unless you are making a prioritising sound FX engine.

 

Or trying to implement a synthesizer, which is what I rather suspect is going on here.  :)



#66 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 5:59 PM

 

Or trying to implement a synthesizer, which is what I rather suspect is going on here.  :)

 

|:) :evil:

 

I can think of a few other uses, but yeah - I'm not exactly hiding what I'm working on. It took me surprisingly little effort to make it functional. Now I just have to write some logic to translate keys into frequencies, and the basic framework is complete. First homebrew Music Synthesizer program? How many did Mattel even bother with? 1 released, and a couple of unfinished prototypes?

 

Even though the synth market is rather ... limited (based on serial numbers I think they sold maybe 10,000 of these things?), I think it's safe to say that a lot of people interested in homebrew own an ECS - these extra sound channels are a godsend. I'm just starting to realize how much.



#67 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 6:23 PM

Ah, my kingdom for a full floating point implementation (and exponentiation). Plus the horsepower to calculate it.

 

Lookup tables to the rescue!



#68 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,827 posts
  • Location:@R6 (top of stack)

Posted Sat Oct 24, 2015 7:15 PM


I can think of a few other uses, but yeah - I'm not exactly hiding what I'm working on. It took me surprisingly little effort to make it functional. Now I just have to write some logic to translate keys into frequencies, and the basic framework is complete. First homebrew Music Synthesizer program? How many did Mattel even bother with? 1 released, and a couple of unfinished prototypes?

 

Well, there's this one I released awhile back:  http://atariage.com/...ards/?p=2464183

 

It didn't have programmable patches or anything, though.

 

I also have a program I need to polish up for release, probably right behind LTO Flash!  It takes the synth idea a big step further:  It scans the synth keyboard and hand controllers and sends keyup/keydown events out over serial.  It receives PSG and voice parameters to play via serial also.

 

This lets you do all sorts of heavy duty computation on a PC, but still use the synth keyboard for input and the PSGs for output.

 

EDIT: It appears I hadn't actually posted the synth.zip that was meant to go with the post I linked above.  I just edited that post to have the source archive along with the binary.

 

Ah, my kingdom for a full floating point implementation (and exponentiation). Plus the horsepower to calculate it.

 

Lookup tables to the rescue!

 

I assume you want a pow(2.0, n/12.0), eh?  :)


Edited by intvnut, Sat Oct 24, 2015 7:24 PM.


#69 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Sat Oct 24, 2015 8:02 PM

And now for an actual IntyBASIC question/problem:

 

Oscar, I thought the NTSC/PAL detection was working (I swear I tested it...). However, this:

IF NTSC = 1 THEN PRINT AT 1,"ntsc" ELSE PRINT AT 1,"pal"

always prints NTSC no matter what. Even when I specify --pal with jzintv. And I KNOW that the --pal switch is working (I think?), because SOUND is the wrong pitch when --pal is turned on. Also just printing NTSC always gives me 1.

 

Did I forget something in terms of how this works?



#70 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,978 posts
  • Coding something good
  • Location:Mexico City

Posted Sat Oct 24, 2015 8:18 PM

And now for an actual IntyBASIC question/problem:

 

Oscar, I thought the NTSC/PAL detection was working (I swear I tested it...). However, this:

IF NTSC = 1 THEN PRINT AT 1,"ntsc" ELSE PRINT AT 1,"pal"

always prints NTSC no matter what. Even when I specify --pal with jzintv. And I KNOW that the --pal switch is working (I think?), because SOUND is the wrong pitch when --pal is turned on. Also just printing NTSC always gives me 1.

 

Did I forget something in terms of how this works?

 

I'm surprised :o I don't have changed anything in that section in a long time...

 

The intybasic_prologue.asm looks good, I'll check it Monday.



#71 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,827 posts
  • Location:@R6 (top of stack)

Posted Sun Oct 25, 2015 9:39 PM

 

I'm surprised :o I don't have changed anything in that section in a long time...

 

The intybasic_prologue.asm looks good, I'll check it Monday.

 

I just ran the PAL/NTSC check in the current version of jzIntv, and the two counts I get for the loop are 444 and 596. 

 

The count should always be higher for PAL than for NTSC, as PAL machines have 1MHz CPUs and only a 50Hz interrupt rate, while NTSC machines have 895kHz CPUs and a 60Hz interrupt rate.  You get 20000 cycles between interrupts on the PAL machine, but only 14934 on NTSC.

 

In your code, though, you use a smaller number for PAL, which doesn't make any sense to me:

.

        ; 387 for PAL in jzintv
        ; 444 for NTSC in jzintv
        CMPI #415,R2
        MVII #1,R0
        BGE _MAIN3
        CLRR R0
_MAIN3: MVO R0,_ntsc

.

At one time I had messed up the CPU rate for PAL in jzIntv, but I've since fixed it.  I don't think I messed it up badly enough to give a smaller number for PAL on this loop, though.  I would've noticed that.

 

You'll want a number more like 520 as your threshold, not 415.


Edited by intvnut, Sun Oct 25, 2015 9:40 PM.


#72 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,978 posts
  • Coding something good
  • Location:Mexico City

Posted Mon Oct 26, 2015 10:51 AM

 

I just ran the PAL/NTSC check in the current version of jzIntv, and the two counts I get for the loop are 444 and 596. 

 

The count should always be higher for PAL than for NTSC, as PAL machines have 1MHz CPUs and only a 50Hz interrupt rate, while NTSC machines have 895kHz CPUs and a 60Hz interrupt rate.  You get 20000 cycles between interrupts on the PAL machine, but only 14934 on NTSC.

 

In your code, though, you use a smaller number for PAL, which doesn't make any sense to me:

.

        ; 387 for PAL in jzintv
        ; 444 for NTSC in jzintv
        CMPI #415,R2
        MVII #1,R0
        BGE _MAIN3
        CLRR R0
_MAIN3: MVO R0,_ntsc

.

At one time I had messed up the CPU rate for PAL in jzIntv, but I've since fixed it.  I don't think I messed it up badly enough to give a smaller number for PAL on this loop, though.  I would've noticed that.

 

You'll want a number more like 520 as your threshold, not 415.

 

I suppose I was using an old version of jzintv. So far everyone can change in intybasic_prologue.asm the 415 to 520 as suggested by intvnut.



#73 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,827 posts
  • Location:@R6 (top of stack)

Posted Mon Oct 26, 2015 11:08 AM

 

I suppose I was using an old version of jzintv. So far everyone can change in intybasic_prologue.asm the 415 to 520 as suggested by intvnut.

 

I just checked Beta4, and the PAL side gives 566, which is slightly smaller than what the latest build gives.  (This makes sense; I had set the CPU MHz too low, but still higher than NTSC.)   A threshold of 520 will work for Beta4 and the current stable dev build.



#74 freewheel OFFLINE  

freewheel

    River Patroller

  • 2,947 posts

Posted Mon Oct 26, 2015 8:01 PM

What's weird is that I specifically used the --pal flag and the NTSC value to calibrate timing in Desert Bus, and it worked flawlessly. Down to within about 3 seconds when simulated out to 8 hours! Now I'm really confused... the timing code came from an example by intvnut, but I can't see you taking into account IntyBASIC's "minor issue".

 

Weird.



#75 nanochess OFFLINE  

nanochess

    River Patroller

  • Topic Starter
  • 4,978 posts
  • Coding something good
  • Location:Mexico City

Posted Mon Oct 26, 2015 9:07 PM

What's weird is that I specifically used the --pal flag and the NTSC value to calibrate timing in Desert Bus, and it worked flawlessly. Down to within about 3 seconds when simulated out to 8 hours! Now I'm really confused... the timing code came from an example by intvnut, but I can't see you taking into account IntyBASIC's "minor issue".

 

Weird.

 

I'm surprised. I had ran my own test long time ago, maybe the weekend I can check this.







Also tagged with one or more of these keywords: Intellivision, IntyBASIC

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users