Previous Thread
Next Thread
Print Thread
Page 38 of 39 1 2 36 37 38 39
Re: 8bit Apples - Apple I, II, /// and the 16 bit GS [Re: Golden Child] #115266
05/11/19 08:02 PM
05/11/19 08:02 PM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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+S*16+0),PEEK(49280+S*16+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+S*16  :  REM 0XC080 + SLOT*16
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


[Linked Image]

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 [Re: Golden Child] #115267
05/12/19 01:39 AM
05/12/19 01:39 AM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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′′′′)".

[Linked Image]

[Linked Image]

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS [Re: rfka01] #115268
05/12/19 07:21 AM
05/12/19 07:21 AM
Joined: Sep 2013
Posts: 10
S
Spk Offline
Member
Spk  Offline
Member
S
Joined: Sep 2013
Posts: 10
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!

[Linked Image]

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 [Re: Golden Child] #115271
05/12/19 11:55 AM
05/12/19 11:55 AM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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.



[Linked Image]
Putting them side by side, you can see the bars have shifted vertically:
[Linked Image][Linked Image]
adding "105 HGR" to the program:
[Linked Image]

The text part is solid, it doesn't wiggle at all:
[Linked Image]
Maybe that can give some clues as to what's happening.

Re: 8bit Apples - Apple I, II, /// and the 16 bit GS [Re: Golden Child] #115277
05/12/19 09:38 PM
05/12/19 09:38 PM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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 [Re: rfka01] #115278
05/12/19 11:17 PM
05/12/19 11:17 PM
Joined: Mar 2001
Posts: 16,206
USA
R
R. Belmont Online content
Very Senior Member
R. Belmont  Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,206
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 [Re: Golden Child] #115279
05/13/19 02:17 AM
05/13/19 02:17 AM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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.

[Linked Image]


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 [Re: rfka01] #115280
05/13/19 02:33 AM
05/13/19 02:33 AM
Joined: Mar 2001
Posts: 16,206
USA
R
R. Belmont Online content
Very Senior Member
R. Belmont  Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,206
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 [Re: R. Belmont] #115282
05/13/19 02:37 AM
05/13/19 02:37 AM
Joined: Feb 2014
Posts: 251
G
Golden Child Offline
Senior Member
Golden Child  Offline
Senior Member
G
Joined: Feb 2014
Posts: 251
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 [Re: rfka01] #115283
05/13/19 03:27 AM
05/13/19 03:27 AM
Joined: Mar 2001
Posts: 16,206
USA
R
R. Belmont Online content
Very Senior Member
R. Belmont  Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,206
USA
mame apple2e -listslots shows all the connectable things going on.

Page 38 of 39 1 2 36 37 38 39

Who's Online Now
1 registered members (Dam0), 35 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
Shout Box
Forum Statistics
Forums9
Topics8,654
Posts113,414
Members4,846
Most Online324
Dec 20th, 2018
Powered by UBB.threads™ PHP Forum Software 7.6.1.1
(Release build 20180111)
Page Time: 0.087s Queries: 14 (0.066s) Memory: 5.7426 MB (Peak: 5.9636 MB) Zlib enabled. Server Time: 2019-05-26 07:06:10 UTC