Jump to content

Photo

How come there hasn't been any new Apple II games in like 10+ years?


108 replies to this topic

#51 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,342 posts

Posted Fri Apr 19, 2013 11:03 PM

Just buy a IIgs instead of messing with GEOS. Eeewww

Edited by JamesD, Fri Apr 19, 2013 11:04 PM.


#52 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Wed May 1, 2013 5:07 AM

i've been tinkering a little and, according to this page, the "value at $c054 [is] equal to the byte being displayed" - that's very useful and i have "working" test code based on it that AppleWin seems happy with, but do we know how consistent this technique is across the range of hardware?

And if we don't have a definitive answer, is there anyone with real hardware and a way to transfer files from teh interwebs who fancies running some test code so we can answer that question? =-)

#53 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Wed May 1, 2013 7:15 PM

i've been tinkering a little and, according to this page, the "value at $c054 [is] equal to the byte being displayed" - that's very useful and i have "working" test code based on it that AppleWin seems happy with, but do we know how consistent this technique is across the range of hardware?

And if we don't have a definitive answer, is there anyone with real hardware and a way to transfer files from teh interwebs who fancies running some test code so we can answer that question? =-)


How long is your Code?? A small Assembly Language routine can be typed into a Real Apple, also a Bootable Disk Image can be made and Downloaded and Transfered to your favorite Apple..

I have some real Hardware.. My Apple ][ will run for a few minutes before freezing. My Apple ][+ needs some Hardware Transplants, and I have a bunch of Apple ][e, both Enhansed and Not Enhansed, and Two Apple ][+, ][e Mice..

#54 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,392 posts
  • Location:Portland, Oregon

Posted Wed May 1, 2013 11:05 PM

I can run code for you, but not until next week. Getting ready for a Propeller expo right now. The second gen chip is out of this world fun, and I've got it on an FPGA right now and need to do some show 'n tell.

IMHO, that byte is consistent across the machines. I've a //e Platinum, which also supplies VBLANK directly... It's in great shape, runs well, has super serial, disk controller, 80 column / double high-res option and CFFA, which I use a USB flash drive with.

What is your dev setup TMR?

#55 Osgeld OFFLINE  

Osgeld

    River Patroller

  • 3,671 posts
  • Location:Nashville, TN

Posted Wed May 1, 2013 11:29 PM

not that you were talking to me, my dev setup is a emulator most of the time or my apple IIc which is equivlant to a //e plat, mouse card 80 column and double high res, working on a stand alone device for a virtual serial drive

#56 JamesD OFFLINE  

JamesD

    Quadrunner

  • 7,342 posts

Posted Wed May 1, 2013 11:49 PM

How long is your Code?? A small Assembly Language routine can be typed into a Real Apple, also a Bootable Disk Image can be made and Downloaded and Transfered to your favorite Apple..

I have some real Hardware.. My Apple ][ will run for a few minutes before freezing. My Apple ][+ needs some Hardware Transplants, and I have a bunch of Apple ][e, both Enhansed and Not Enhansed, and Two Apple ][+, ][e Mice..

That wouldn't have to be very long. Set the graphics mode, clear the screen, write a byte to the last screen address and then read that address in a loop until it finds the non-zero byte you wrote to the screen. The first part is just monitor calls. I'm guessing it should be well under 50 bytes even if you output something once you detect the proper value.
If you kick off an interrupt from a 6522 right after you detect that byte it would give you a consistent VBLANK interrupt equivalent.
Maybe you wouldn't use the last byte of the screen to eliminate the few cycles needed to finish setting up the 6522.
As long as all machines support it, that's doable. You could even skip the interrupt and just poll for a specific value but the drawback would be you couldn't use that value in any of your graphics.

#57 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 1:29 AM

How long is your Code?? A small Assembly Language routine can be typed into a Real Apple, also a Bootable Disk Image can be made and Downloaded and Transfered to your favorite Apple..


Fourteen lines of actual code since it just runs in the default text mode. i've attached a disk image which draws a line of inverted spaces a few lines up from the bottom of the screen and, if the sync routine works, the top left byte of the screen RAM should keep changing.

I have some real Hardware.. My Apple ][ will run for a few minutes before freezing. My Apple ][+ needs some Hardware Transplants, and I have a bunch of Apple ][e, both Enhansed and Not Enhansed, and Two Apple ][+, ][e Mice..


It'd be nice to get a definitive answer to what this technique works on, so whatever you've got time to throw it at would be good. =-)

Attached File  sync_test.zip   122bytes   63 downloads

Edited by TMR, Thu May 2, 2013 1:30 AM.


#58 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 1:38 AM

I can run code for you, but not until next week.


Cool, the more the merrier. =-)


IMHO, that byte is consistent across the machines. I've a //e Platinum, which also supplies VBLANK directly... It's in great shape, runs well, has super serial, disk controller, 80 column / double high-res option and CFFA, which I use a USB flash drive with.


That's what i'm interested in really, is it consistent across the range and is that regardless of extra hardware (i'm assuming the card-based graphics expansions don't work in the same way but has that ever been tested...?)

What is your dev setup TMR?


i'm just using ACME to assemble, CiderPress to wedge the obect code into a disk image and AppleWin for testing. This is why i'm asking folks to test on real hardware, i tried the RDVBLBAR approach and AppleWin insisted it would work on an Apple II+ despite everyone saying it shouldn't!

#59 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,392 posts
  • Location:Portland, Oregon

Posted Thu May 2, 2013 7:32 AM

@Osgeld, and your toolchain is?

@TMR, James: There is the currently displayed byte, but there are also the undisplayed areas, which do get scanned. IMHO, you can write to the regions that aren't actually graphics and see them. This is described in the Sather books. e and c machines offer a signal additionally, but still operate the same way the older machines did.

I would for sure test these cases, writing to the screen memory holes. I believe they get scanned during blanks, and such. Or parts of them do.

#60 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 8:08 AM

Fourteen lines of actual code since it just runs in the default text mode. i've attached a disk image which draws a line of inverted spaces a few lines up from the bottom of the screen and, if the sync routine works, the top left byte of the screen RAM should keep changing.



It'd be nice to get a definitive answer to what this technique works on, so whatever you've got time to throw it at would be good. =-)

Attached File  sync_test.zip   122bytes   63 downloads


Your Disk Images is now Damaged.. The Zip File is 122 Bytes, and the sync_test.do is Zero Bytes..

#61 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 8:10 AM

<, SNIP >>

I would for sure test these cases, writing to the screen memory holes. I believe they get scanned during blanks, and such. Or parts of them do.


The Mouse Firmware uses some of the Screen Holes too.. I will look for the Documentation I downloaded...

#62 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 10:47 AM

I found these:


http://apple2online....nical_notes.pdf

http://apple2.org.za...a2pfaq.html#012

#63 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 1:03 PM

Your Disk Images is now Damaged.. The Zip File is 122 Bytes, and the sync_test.do is Zero Bytes..


Oh crap... guess who forgot to eject the disk image before archiving it...

Attached File  sync_test.zip   7.27KB   61 downloads

#64 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 1:09 PM

@TMR, James: There is the currently displayed byte, but there are also the undisplayed areas, which do get scanned. IMHO, you can write to the regions that aren't actually graphics and see them. This is described in the Sather books. e and c machines offer a signal additionally, but still operate the same way the older machines did.

I would for sure test these cases, writing to the screen memory holes. I believe they get scanned during blanks, and such. Or parts of them do.


Oh great... okay, so what i'm currently doing is drawing a line across the screen and checking for the byte in that line... if i check for multiple instances, what are the odds of the RAM in those gaps having the same pattern... or can i just write to that space and be sure of it's contents?

i think this goes quite a way to disproving what high voltage said about the A2 flooring the C64 for programming though!

#65 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 1:13 PM

Oh crap... guess who forgot to eject the disk image before archiving it...

Attached File  sync_test.zip   7.27KB   61 downloads


It's "Got To Be You"......

Excellent... It Extracts and Runs in AppleWin 1.20.0.0...

#66 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 1:24 PM

Oh great... okay, so what i'm currently doing is drawing a line across the screen and checking for the byte in that line... if i check for multiple instances, what are the odds of the RAM in those gaps having the same pattern... or can i just write to that space and be sure of it's contents?

i think this goes quite a way to disproving what high voltage said about the A2 flooring the C64 for programming though!


Your Loader Program is in AppleSoft.. This Won't run on an Apple ][ with the Language Card..

Will it invalidate your Test to move the HELLO and SYNC Programs to a System Master Disk with the AppleSoft, or Write an Integer Basic Loader for your Disk??


#67 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 1:46 PM

Your Loader Program is in AppleSoft.. This Won't run on an Apple ][ with the Language Card..


Basically, that's because i'm a C64 coder by "trade", totally winging it here and didn't realise that'd be a problem... =-) So the next question is "is there a universal way to boot a disk then?"

Will it invalidate your Test to move the HELLO and SYNC Programs to a System Master Disk with the AppleSoft, or Write an Integer Basic Loader for your Disk??



My code shouldn't care what's booting it as long as the text screen doesn't contain any inverted spaces before execution; if that happens, it might fire the update routine more than once.

#68 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 2:09 PM

Basically, that's because i'm a C64 coder by "trade", totally winging it here and didn't realise that'd be a problem... =-) So the next question is "is there a universal way to boot a disk then?"


That is Not a Problem.. I own an SX-64 and it is a Very nice Machine....

Yes, there is.....


My code shouldn't care what's booting it as long as the text screen doesn't contain any inverted spaces before execution; if that happens, it might fire the update routine more than once.


There is a way of having One of each program ( Integer Basic and Applesoft Basic ) and in the case of an Apple ][ or ][+ with a Language Card with Only One Basic loaded at Boot Time, running the Basic Program that is Supported.

I have an Integer Basic Program, but it Won't Auto Start ( yet ) with AppleWin set as an Apple][.

10 CALL -936
20 PRINT "BRUN SYNC"
30 END

( Note there is an Invisible Control-D after the opening Quote and Before the BRUN.. )

I am rediscovering how the DOS System Master makes this kind of Magic happen....



#69 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,392 posts
  • Location:Portland, Oregon

Posted Thu May 2, 2013 2:47 PM

The "screen holes" are writable RAM. Just clear them, if you want to insure a unique value, or better, put your value there, and sync off of it without worrying about it being on the real screen.

#70 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,392 posts
  • Location:Portland, Oregon

Posted Thu May 2, 2013 2:59 PM

i think this goes quite a way to disproving what high voltage said about the A2 flooring the C64 for programming though!


Well, let's not get out of hand on this, but... The Apple is GREAT for programming lots of things. Good tools right in the box, and if one goes looking, languages, and many other tools out there. There is also then and today. Today, those things matter much less, but then? Yeah, Apples were great. When I first moved to Atari after doing a lot of stuff on an Apple ][, it was very restrictive. I didn't have a monitor, no quick assembler, etc... Some purchases later, the big one being the OSS packages, I was kind of set, but for that 80 column screen.

Now, when it comes to this kind of programming? IMHO, it's going to be new ground for most people.

#71 Keatah ONLINE  

Keatah

    Quadrunner

  • 17,259 posts

Posted Thu May 2, 2013 3:15 PM

Programming the Apple II is nice because the machine doesn't impose a lot of machine personality on you. You are responsible for everything that goes on.

#72 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 6:04 PM

Well, let's not get out of hand on this, but... The Apple is GREAT for programming lots of things. Good tools right in the box, and if one goes looking, languages, and many other tools out there.


That's all true of the C64 as well though, and a good selection of tools were available either for the price of a game or in some cases less; my assembler for fifteen years cost £8.99 new by the time i was buying (and i got it second hand), the sprite and character tools i used for even longer were free and the music tool used for my first real game was £2.99, with all the commercial stuff available off the shelf at our local indie computer shop.

Now, when it comes to this kind of programming? IMHO, it's going to be new ground for most people.


Yeah, i'm starting to see that... but since people know how these techniques work, is it really new ground in the truest sense?

(And yes, i'm "filling" at the moment whilst waiting for feedback on the code; i wrote a game using this sync technique already but i don't want to release even a beta until i'm reasonably sure it's a reliable method! =-)

#73 TMR ONLINE  

TMR

    River Patroller

  • 3,325 posts
  • Beeping the horn on the data bus
  • Location:Leeds, U.K.

Posted Thu May 2, 2013 6:13 PM

Programming the Apple II is nice because the machine doesn't impose a lot of machine personality on you. You are responsible for everything that goes on.


That's true of every 8-bit including the C64 though - yes there's hardware sprites and scrolling, but they're optional. If you wanted to be different, it's possible to treat the C64 like an Apple II but with a different screen configuration, that's pretty much how ported games like Repton or Bandits do things.

Edited by TMR, Thu May 2, 2013 6:13 PM.


#74 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 6:56 PM

Well... A "real" Apple //e Enhanced looks good.. It does have a Mouse Card in it, but I tested first with it, and then without the Mouse Card..

Video:
With an Apple Mouse Card and Mouse

Without an Apple Mouse Card and Mouse

( Now residing at TMR's Real Apple Sync Test )

#75 MarkO OFFLINE  

MarkO

    Dragonstomper

  • 805 posts
  • Location:Albany, Oregon, USA, North Western Hemisphere, Planet Tera

Posted Thu May 2, 2013 7:40 PM

Well, my Apple ][ has some Technical Issues, most Important is a Poor Quality Video Signal..

My Composite to VGA Adapter is having a Hard Time getting a Sync...
See Apple ][ Video Test #2.

I seem to remember that the Apple /// Monitor is much more "forgiving".. I will need to plug it in to that Monitor and Test again...

What exactly does the Failure of the Sync Program display???



Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users