and the 16 bit GS

Print Thread

Page 38 of 80

…

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child #115266 05/11/19 08:02 PM
Joined: Feb 2014 Posts: 1,102 Likes: 173 G Golden Child Very Senior Member
Golden Child Very Senior Member G Joined: Feb 2014 Posts: 1,102 Likes: 173	I keep fiddling with it and I think that maybe the lower set of addresses (C0F0-C0F8) are the upper switches and the higher addresses are the lower switches (C0F8-C0FF). I suppose it has to be one or the other, and I think that's correct. It would make sense as the bar on screen will appear on pressing the lower switch and disappear on releasing the upper switch. It would be good to run a little test program on a real Syntauri keyboard that would read those addresses. just something simple like: 100 S=7:PRINT PEEK(49280+S16+0),PEEK(49280+S16+8):GOTO 100 REM SLOT 7 = C0F0 and then press the lowest key on the keyboard slowly. Here's a short little program, and if you push the key down slowly enough it should show you which io location changes first: Code 100 S=7:IO=49280+S16 : REM 0XC080 + SLOT16 110 U=PEEK(IO):D=PEEK(IO+8) 120 IF U<>U0 OR D<>D0 THEN PRINT U" "D 125 U0=U:D0=D 130 GOTO 110 So when a key goes down it first hits the upper switch, and then the lower switch, the time delay being a measure of how fast you're pressing the key down. delay = 0.026316 very quiet delay = 0.013158 quiet delay = 0 loudest It doesn't seem to have many gradations in between loud and quiet. I hooked up my Sidewinder Precision Pro's throttle wheel (closest thing I've got to a paddle controller) to the joystick 2 x axis and set my delay to: mykeysecondtimedown=machine().time().as_double()+(1.0/1520/100)m_joy2x->read()10; // the joystick reads between 0-255 and I can't hear too much in between the loud and the soft. Last edited by Golden Child; 05/11/19 10:30 PM.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child #115267 05/12/19 01:39 AM
Joined: Feb 2014 Posts: 1,102 Likes: 173 G Golden Child Very Senior Member
Golden Child Very Senior Member G Joined: Feb 2014 Posts: 1,102 Likes: 173	Found a 1980 brochure for AlphaSyntauri on archive.org: https://archive.org/details/TNM_alphaSyntauri_live_music_on_Apple_computer_-__20180131_0046 I think they mean from C to C not F to F. Wikipedia says "The modern console specification recommended by the American Guild of Organists calls for manual keyboards with sixty-one notes (five octaves, from C to c′′′′)".

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS rfka01 #115268 05/12/19 07:21 AM
Joined: Sep 2013 Posts: 14 S Spk Member
Spk Member S Joined: Sep 2013 Posts: 14	Thank you very much for the SCSI command info! I got it working and proceded to try a drive-hooked-up IIgs. Connected: 5.25 drive: BlankProdos.dsk 3.5 drive: PrintShopGS.2mg SCSI cdrom: GO.iso SCSI hardrive: SCSIHD.chd (not booted) VULCAN.GOLD hardrive: VULCAN.chd (boot) RAM-Drive: 4MB Everything works nicely. What a machine! Obviously the IIgs slots (nvram) must be set accordingly. In my case I went with: Slot2: Your card, Slot7: Your card, Boot: Scan, and set a RAM-Drive to 4MB Example command: D:\Mame>mame64 apple2gs -ramsize 8M -flop1 D:\Mame\software\apple2gs\BlankProdos.dsk -flop3 D:\Mame\software\apple2gs\PrintShopGS.2mg -sl2 scsi -sl2:scsi:scsibus:1 cdrom -cdrom1 D:\Mame\software\apple2gs\GO.iso -sl2 scsi -sl2:scsi:scsibus:6 harddisk -hard1 D:\Mame\software\apple2gs\SCSIHD.chd -sl7 vulcangold -hard2 D:\Mame\software\apple2gs\VULCAN.chd Cheers Last edited by Spk; 05/12/19 11:28 AM. Reason: figured out how to get the pic to display

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child #115271 05/12/19 11:55 AM
Joined: Feb 2014 Posts: 1,102 Likes: 173 G Golden Child Very Senior Member
Golden Child Very Senior Member G Joined: Feb 2014 Posts: 1,102 Likes: 173	I hardly ever use GR mode, but happened to end up in it after breaking out of Alphaplus, and noticed that if you print text that makes the screen scroll, it will make the screen vertically shift. 100 GR:FOR I=0 TO 39:R=RND(1)*16:COLOR=R:HLIN 0,39 AT I:NEXT 110 PRINT : GOTO 110 the screen will "wiggle". It's actually kind of a neat effect. Interestingly, whenever it wiggles, it causes a partial screen update message to display if I turn on the frameskip osd with F11. If you vary the frameskip, you can see the numbers change on the partial screen update message. If I set frameskip to 10/10 the partial screen update numbers slow down where you can actually read them. Also, if you put an HGR in the above program, like 105 HGR the screen glitches show up. It's interesting that the CALL -912 routine at FC70 makes some hits to softswitches. Printing text in the print statement shows that the text window part doesn't wiggle. If I change line 110 to 110 CALL -912 : GOTO 110 it will do the same thing. Putting them side by side, you can see the bars have shifted vertically: adding "105 HGR" to the program: The text part is solid, it doesn't wiggle at all: Maybe that can give some clues as to what's happening.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS

Golden Child #115277 05/12/19 09:38 PM

Joined: Feb 2014

Posts: 1,102

Likes: 173

Golden Child Online Content

Very Senior Member

Golden Child

Very Senior Member

Joined: Feb 2014

Posts: 1,102

Likes: 173

I think I know why the GR screen wiggles when the screen scrolls.

The scroll routine hits softswitches c054 and c055 which causes partial updating to occur.

I put a little printf to show me what was happening:

In the apple2e_state:screen_update routine:

Code

       else    // lo-res
                {
                        if (m_video->m_mix)
                        {
                                if ((m_video->m_dhires) && (m_video->m_80col))
                                {
                                        m_video->dlores_update(screen, bitmap, cliprect, 0, 159);
                                }
                                else
                                {       if (m_joybuttons->read() & 0x40) printf("cliprect = top bot %d,%d, left rt %d,%d  wid ht  %d,%d\n",cliprect.top(),cliprect.bottom(),cliprect.left(),cliprect.right(),cliprect.width(),cliprect.height());
                                        m_video->lores_update(screen, bitmap, cliprect, 0, 159);
                                }

Code

cliprect = top bot 0,85, left rt 0,559  wid ht  560,86
cliprect = top bot 86,86, left rt 0,254  wid ht  255,1
getting to the switch  offset=54
cliprect = top bot 86,86, left rt 254,559  wid ht  306,1
cliprect = top bot 87,191, left rt 0,559  wid ht  560,105
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
getting to the switch  offset=55
cliprect = top bot 0,19, left rt 0,559  wid ht  560,20
cliprect = top bot 20,20, left rt 0,2  wid ht  3,1
getting to the switch  offset=54
cliprect = top bot 20,20, left rt 2,366  wid ht  365,1
cliprect = top bot 20,191, left rt 0,559  wid ht  560,172
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
getting to the switch  offset=55
getting to the switch  offset=54

and when it hits the softswitch, it triggers a partial update

Code

 
              case 0x54:  // set page 1
                        if (!m_video->m_80col)
                        {
                                m_screen->update_now();   // This must trigger the partial update
                        }
                        m_page2 = false;
                        m_video->m_page2 = false;
                        auxbank_update();
                        break;

                case 0x55:  // set page 2
                        if (!m_video->m_80col)
                        {
                                m_screen->update_now();
                        }
                        m_page2 = true;
                        m_video->m_page2 = true;
                        auxbank_update();
                        break;

without the switches being hit, it will do an update all at once:

Code

cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192
cliprect = top bot 0,191, left rt 0,559  wid ht  560,192

So I think what's happening is that it's coming into the lores_update with a non multiple of 8 as the top of the cliprect.

If we and the row with 0xf8 we can lock it to a multiple of 8 and set our starty to row % 8. That seems to fix the wiggle (just in my limited testing.)

Code

  beginrow = (std::max)(beginrow, cliprect.top());
        endrow = (std::min)(endrow, cliprect.bottom());

        if (!(m_sysconfig & 0x03))
        {
                for (row = beginrow; row <= endrow; row += 8)
                {
                        for (col = 0; col < 40; col++)
                        {
                                /* calculate adderss */      // adderss 8-)
                                address = start_address + ((((row/8) & 0x07) << 7) | (((row/8) & 0x18) * 5 + col));

                                /* perform the lookup */
                                code = m_ram_ptr[address];

                                int starty = row % 8;   // get the low three bits

                                /* and now draw */
                                for (y = starty; y < 4; y++)   // start from starty
                                {
                                        if ((row + y) <= endrow)
                                        {
                                                for (x = 0; x < 14; x++)
                                                {
                                                        bitmap.pix16((row & 0xf8) + y, col * 14 + x) = (code >> 0) & 0x0F;    // and the row with 0xf8
                                                }
                                        }
                                }
                                for (y = starty+4; y < 8; y++)  // start from starty + 4
                                {
                                        if ((row + y) <= endrow)
                                        {
                                                for (x = 0; x < 14; x++)
                                                {
                                                        bitmap.pix16((row & 0xf8) + y, col * 14 + x) = (code >> 4) & 0x0F;
                                                }
                                        }
                                }
                        }
                }
        }

That got me to thinking, maybe the hgr_update routine is getting a little confused with getting different cliprects coming in, this modification seems to solve most of the glitching (though I did see a little speckle now and then).

(I don't completely understand the routine, so my assumptions may be wrong)

Code

void a2_video_device::hgr_update(screen_device &screen, bitmap_ind16 &bitmap, const rectangle &cliprect, int beginrow, int endrow)
...

      for (row = beginrow; row <= endrow; row++)
        {
                for (col = begincol; col < endcol; col++)
                {
                        offset = ((((row/8) & 0x07) << 7) | (((row/8) & 0x18) * 5 + col)) | ((row & 7) << 10);
                        vram_row[1+col] = vram[offset];
                }

//              p = &bitmap.pix16(row);
//              for (col = 0; col < 40; col++)

                for (col = begincol; col < endcol; col++)     // if we wanted to limit it to the cliprect start at begincol and end at endcol
                {
                p = &bitmap.pix16(row,col*14);  // update the p pointer for the start of our row and col


                        w =     (((uint32_t) vram_row[col+0] & 0x7f) <<  0)
                                |   (((uint32_t) vram_row[col+1] & 0x7f) <<  7)
                                |   (((uint32_t) vram_row[col+2] & 0x7f) << 14);

Last edited by Golden Child; 05/12/19 11:01 PM.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS rfka01 #115278 05/12/19 11:17 PM
Joined: Mar 2001 Posts: 17,217 Likes: 234 USA R R. Belmont Very Senior Member
R. Belmont Very Senior Member R Joined: Mar 2001 Posts: 17,217 Likes: 234 USA	The understanding of the routine is that French Touch and Deater both switch video modes arbitrarily in their stuff. Text, then HGR, then GR, then text on the bottom in Deater's most well-known case; French Touch went with HGR on the left and GR on the right IIRC. It's not exactly emulating that case properly but it's closer than it used to be.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS Golden Child #115279 05/13/19 02:17 AM
Joined: Feb 2014 Posts: 1,102 Likes: 173 G Golden Child Very Senior Member
Golden Child Very Senior Member G Joined: Feb 2014 Posts: 1,102 Likes: 173	Wow, just got done looking at the http://www.appleii-box.de website's syntauri pages and they're amazing in the level of detail and completeness. Seriously amazing, I wish I knew how to read schematics well. Some of the disk images are completely blank. They must share a common source with the Science Fiction Writer site. hexdump -C ../../SUPERPLUS_from_APPLEBOX.dsk 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| * 00023000 hexdump -C ../../DEMOSNOTES_FROM_APPLEIIBOX.dsk 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| hexdump -C ../../EXAMPLES_FROM_APPLEBOX.dsk 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| hexdump -C ../../ALPHAPLUS_FROM_APPLEBOX.dsk 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \|................\| I also found a bunch of .NIB files on another site but that's not directly loadable in mame now, any suggestions on how to convert .nibs? Last edited by Golden Child; 05/13/19 02:21 AM.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS rfka01 #115280 05/13/19 02:33 AM
Joined: Mar 2001 Posts: 17,217 Likes: 234 USA R R. Belmont Very Senior Member
R. Belmont Very Senior Member R Joined: Mar 2001 Posts: 17,217 Likes: 234 USA	Does CiderPress read .nibs? Otherwise you can -sl6 diskii to use the old HLE disk controller in MAME and run .nibs.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS R. Belmont #115282 05/13/19 02:37 AM
Joined: Feb 2014 Posts: 1,102 Likes: 173 G Golden Child Very Senior Member
Golden Child Very Senior Member G Joined: Feb 2014 Posts: 1,102 Likes: 173	Thanks, RB, I'll give it a try. I didn't know you could use the old HLE controller. Cool! So many things to learn. 8-) edit: I'm beginning to think the .nib images that I found aren't any good as the HLE disk ii didn't like them. Neither did nib2dsk or ciderpress 3.01, or applewin or applepc. Can .nib files be in the wrong disk order? (just to test my sanity, the HLE disk ii seemed to work fine as it booted Microsoft Decathlon.nib) Last edited by Golden Child; 05/13/19 03:50 AM.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS rfka01 #115283 05/13/19 03:27 AM
Joined: Mar 2001 Posts: 17,217 Likes: 234 USA R R. Belmont Very Senior Member
R. Belmont Very Senior Member R Joined: Mar 2001 Posts: 17,217 Likes: 234 USA	mame apple2e -listslots shows all the connectable things going on.

Page 38 of 80

…

Moderated by Bletch, R. Belmont, Richard Bannister

Link Copied to Clipboard