6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: mdj on 5 Jun 2006 23:06 Lyrical Nanoha wrote: > If you're only running 48K apps on DOS 3.x that's easy. Use NEWBASIC > LOADER from Beagle Basic to load FPBASIC off the 1980 DOS 3.3 System > Master. Presto. Apple ][+ ROM on the LC. Sure - works fine for 48k ... Was also nicer on an original Apple II, as pressing reset didn't switch out the language card. In the end it wasn't a big problem - the enhanced ROMS were pretty compatible. I always enjoyed the SmartPort concept that emerged to run the UniDisk 3.5. One of the nicest 8-bit I/O interfaces I've seen. > Because their own project got bogged down in details... Ok.. Wasn't aware there was a replacement project underway...
From: Sam Gillett on 6 Jun 2006 00:50 "Paul Schlyter" wrote ... > In article <1149383070.763983.291190(a)h76g2000cwa.googlegroups.com>, > mdj <mdj.mdj(a)gmail.com> wrote: > >> Hey, we're almost back on topic, considering this was supposed to be >> about 'undocumented opcodes' :-) Of course, my feelings on using >> undocumented library calls is much the same as my feelings on >> undocumented opcodes. They are very similar problems. > > In the Apple II world we had other similar situations: calling Monitor > ROM routines at some fixed address. Or calling routines in the Applesoft > Basic ROM's. Programmers in the Commodore world also made extensive use of calling ROM routines. But, not all of them were undocumented. Commodore listed the entry address for many of the more useful Kernal routines, along with a name for the routine and a brief description of its function, in the C64 Programmer's Reference Guide. When the C128 came along, Commodore also documented Kernal calls for that machine in the C128 PRG. -- Best regards, Sam Gillett Change is inevitable, except from vending machines!
From: sicklittlemonkey on 6 Jun 2006 02:16 mdj wrote: > Of course, but includes include includes (lol), which include others, > which then perhaps collide with one you've already defined. The scope > over which a macro symbol exists is potentially the entire application. > It's entirely non-determinable. Exactly. One reason I'm very happy to be out of the C++ world (for now) is that there wasn't much support for 'compile-time debugging'! And it was sorely needed when includes reached a critical mass. Debugging with preprocessor directives doesn't really cut it. Cheers, Nick.
From: Michael J. Mahon on 6 Jun 2006 03:54 mdj wrote: > Michael J. Mahon wrote: > > >>And, intrestingly, this also returns us to another earlier theme of this >>thread--how widespread use of undocumented features can create a barrier >>to the creation of new, improved implementations. >> >>The Apple ROM was not significantly changed until the //e, where much >>of the actual code was placed in a bank-switched area. Much of the F8 >>region became stubs at documented entry points vectoring to the actual >>routines. Updating the F8 region of the ROM was known to be a minefield >>of compatibility issues. >> >>The notion of defining the ROM entry points more architecturally was >>not widespread at the time the Apple II was designed, and the impact >>of the subsequent loss of control over ROM code became a problem. > > > Yeah - I used to think the best approach would've been an additional > softswitch and an extra ROM chip, providing absolute compatibility with > the old AutoStart ROM. Considering the cost of manufacture of the IIe, > it would've been a simpler solution. > > That said, the engineers that wrote the IIc and enhanced IIe ROMS (I'm > not much of a fan of the original IIe ROM) did a fantastic job. I agree--it's remarkable how much original behavior they preserved while making some really fundamental improvements. > The only real issue for me was a hardware issue, in that the IIe and > IIc had a feature that would reenable the ROM on reset, which annoyed > me a great deal. I know it was necessary to implement the warm boot, > but it would have been nice if that hardware feature only worked while > PB0 was active. I expect the issue was deference to copy protection. They had to keep control of the RESET vector to ensure that it was at least "hard" to break out of a game with all its memory intact. This did interfere with some straightforward approaches to user-friendly systems, however. >>(I've always wondered how much "compatibility issues" and how much >>"renegotiation issues" factored into the decision to never update >>the Applesoft ROMs to fix bugs...) > > > I never really did understand why they licensed a new BASIC from > Microsoft instead of expanding Integer to include the missing features. It's clear that Woz had considered FP, since he had already written the routines. It was probably a case of time pressure, the fact that realistically only Woz could make such a modification to Integer BASIC, and he was busy with other needed improvements (like Disk ][). Couple that pressure with the _de facto_ success of Microsoft BASIC in the marketplace and things shake out the way they did. >>Later systems used a combination of less documentation and more >>complexity to make calls into the middle of ROM less likely. Still >>not an ideal solution, but one well adapted to the Apple II. ;-) > > > The API based approach used in the IIgs was quite nice, particularly > since it allowed the OS to patch broken ROM code at boot time, although > this in itself caused problems. But then only if one ignored the > explicit directions of Apple to NOT jump to absolute locations in ROM. > > But then there were applications that had to be modified to run on > ROM03 IIgs's. Some people never learn .... In fact, some people prided themselves in programming "to the metal"... -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: Michael J. Mahon on 6 Jun 2006 03:57
Sam Gillett wrote: > "Paul Schlyter" wrote ... > > >>In article <1149383070.763983.291190(a)h76g2000cwa.googlegroups.com>, >>mdj <mdj.mdj(a)gmail.com> wrote: >> >> >>>Hey, we're almost back on topic, considering this was supposed to be >>>about 'undocumented opcodes' :-) Of course, my feelings on using >>>undocumented library calls is much the same as my feelings on >>>undocumented opcodes. They are very similar problems. >> >>In the Apple II world we had other similar situations: calling Monitor >>ROM routines at some fixed address. Or calling routines in the Applesoft >>Basic ROM's. > > > Programmers in the Commodore world also made extensive use of calling ROM > routines. But, not all of them were undocumented. Commodore listed the > entry address for many of the more useful Kernal routines, along with a name > for the routine and a brief description of its function, in the C64 > Programmer's Reference Guide. > > When the C128 came along, Commodore also documented Kernal calls for that > machine in the C128 PRG. The Apple II manual documented a couple of dozen monitor routines also, but since the ROM listing was provided, many called other entry points. -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." |