JamesD Posted April 20, 2013 Share Posted April 20, 2013 (edited) Just buy a IIgs instead of messing with GEOS. Eeewww Edited April 20, 2013 by JamesD Quote Link to comment Share on other sites More sharing options...
TMR Posted May 1, 2013 Share Posted May 1, 2013 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? =-) 1 Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 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.. Quote Link to comment Share on other sites More sharing options...
potatohead Posted May 2, 2013 Share Posted May 2, 2013 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? Quote Link to comment Share on other sites More sharing options...
Osgeld Posted May 2, 2013 Share Posted May 2, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted May 2, 2013 Share Posted May 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
TMR Posted May 2, 2013 Share Posted May 2, 2013 (edited) 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. =-) sync_test.zip Edited May 2, 2013 by TMR Quote Link to comment Share on other sites More sharing options...
TMR Posted May 2, 2013 Share Posted May 2, 2013 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! Quote Link to comment Share on other sites More sharing options...
potatohead Posted May 2, 2013 Share Posted May 2, 2013 @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. Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 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. =-) sync_test.zip Your Disk Images is now Damaged.. The Zip File is 122 Bytes, and the sync_test.do is Zero Bytes.. Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 <, 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... Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 I found these: http://apple2online....nical_notes.pdf http://apple2.org.za...a2pfaq.html#012 Quote Link to comment Share on other sites More sharing options...
TMR Posted May 2, 2013 Share Posted May 2, 2013 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... sync_test.zip Quote Link to comment Share on other sites More sharing options...
TMR Posted May 2, 2013 Share Posted May 2, 2013 @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! Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 Oh crap... guess who forgot to eject the disk image before archiving it... sync_test.zip It's "Got To Be You"...... Excellent... It Extracts and Runs in AppleWin 1.20.0.0... Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 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?? Quote Link to comment Share on other sites More sharing options...
TMR Posted May 2, 2013 Share Posted May 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 2, 2013 Share Posted May 2, 2013 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.... Quote Link to comment Share on other sites More sharing options...
potatohead Posted May 2, 2013 Share Posted May 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
potatohead Posted May 2, 2013 Share Posted May 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
Keatah Posted May 2, 2013 Share Posted May 2, 2013 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. Quote Link to comment Share on other sites More sharing options...
TMR Posted May 3, 2013 Share Posted May 3, 2013 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! =-) Quote Link to comment Share on other sites More sharing options...
TMR Posted May 3, 2013 Share Posted May 3, 2013 (edited) 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 May 3, 2013 by TMR Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 3, 2013 Share Posted May 3, 2013 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 ) Quote Link to comment Share on other sites More sharing options...
MarkO Posted May 3, 2013 Share Posted May 3, 2013 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??? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.