The 1st Apple II Emulation Conference log From: rcolb...@oasis.novia.net (Bob Colbert) Subject: Apple // emulatioin IRC conference log Date: 1995/05/04 Message-ID: <3oanht$jku@nntp.novia.net> X-Deja-AN: 102132792 organization: Novia Internetworking, LLC <> 28.8kbps dialup: 402/390-2NET newsgroups: comp.emulators.apple2 Subject: Apple Emulation IRC log Newsgroups: comp.emulators.apple2 Organization: University of Nebraska at Omaha (Student CWIS) Here I go again, tried to post this yesterday, but it never appeared! This is the IRC log of the 1st Apple // emulation conference! kevinL = Author of STM for the Mac MikeO = Author of AppleWin for Windows Munz = Author or Appleworks emulator for Mac ctkwan = Author of YAE, an emulator for UNIX, X-Windows randys = Author of apl2em - one of the first! Saltine= Me - just a guy with aspirations of writing an emulator ah, back from dinner. Saltine - who's kevin K? kevinl: kevin kralian - author of Apple2000 4 Amiga saltine, are you light and crispy? all: I have a way of transfering PROTECTED disks to emulators - Interested? Saltine : yeah.... kevinl - no, just a littl flakey saltine sure, I just put a 1/4 track nibbleized image format into STM, could use some protected images to test it out... salt: sure :) is there a //gs emulator for win16/32? is there a //gs emulator? ;) kevinl: OK, that is one thing we need to discuss - a standardized nibble image Someone is still developing a GS emulator.... virtual GS? that's dead. I was gonna join the effort this september, but it's dead. bummer :( well, here's what I do...a little header that gives track # (*4), track length, then track bytes; repeat as needed. Simple and to the point. kevinl: Do you mean track length for each track? yeah saltine. kevinL- is STM assembled, or from C? eolson: the 6502 module is mainly assembly; STM istelf and the other modules are 99.9% C **** Action : eolson doesn't know much about disk stuff :( eolson : Maybe someone would like to restart Virtual GS kevin- have you considered the PPC port? kngfishr- that's one of my goals. kevinl: What I need for my program to work is a way to change a track length while the emulator is running! eolson: sure, buy me a PPC and I'll do it! saltine: no prob...just hold the image in memory, modify as needed, re-write it on a save... kevinL: hehehe :) eolson : Great... count me in. As soon as I can have a GS emulator, I will move out of my GS, kngfishr- you want to help? :) It's a mighty big undertaking ... sigh. kevinl: Have you ever heard of EDD IV? kevin- do you have codewarrior? eolson : Sure. nope, flaky one. What is it? eolson: nope...no $$, grad studenting pays subsistence wage only... eolson : I am sure I seen the source codes still lying around somewhere.... kngfishr- source code for a GS emulator? Are you sure? (i think someone would have compiled it :) on the subject of a IIgs emulator... kevinl: it was THE copy prog for Apple //, I modified it to capture protected disk images for the emuls I think a IIGS emulator is unlikely to prove worthwhile. Think about how much effort is going into the task of a simple Apple II. eolson : unfinished work.... bits and pieces of the different units.... my next move with STM will to be to add more flexible memory management to the central (STM app) portion... kngfishr- you mean the virtual GS project? eolson : I think so.... seen it at a FTP site.... at that point, modules for the IIgs could be plugged in a bit at a time, to simplify development. kevin- how is your program structured? I know you have a bunch of modules, but how are they interacting? Does each module have domain over a particular area of Cx00? I'm thinking of implementing the Ensoniq chip as a module for STM just for laughs; it's just look like a sound card. eolson: a module just registers addresses it wants to handle; STM calls it when they're accessed. I don't see sound emulation as being as important... as, say... processor and video. kevinL : The biggest problem will likely be the Toolbox okay, so a hit on $c010 would do what? eolson: yeah, but I'm more interested in throwing the sound chip together... kngfishr- just emulate it. hi everyone kevin- i'm sure ensoniq would be easier than tweaked sound. I think if someone can hexdump the Mega II chip would be cool. greets MikeO eolson: well, a module will say "here's a pointer to a function which I want called when $C010 is read" eolson: the function will return an unsigned char to STM. kevin- okay... eolson: and of course a imilar process for writes. kevin- (btw- m'name is ed) That doesn't seem terribly efficient. Are there any other approaches? then modules get other messages, like expansion rom on/off; they can request events passed in , window update messages, etc. kevin- do you have a function then for every address Cxxx? ed: well, I can't think of any. Nope, just functions registered where modules want to be; the rest acts like rom... kevin- I was thinking of setting up a 64k bank of memory (whatever, taking into account langauge card crap.) Then, on reads and writes, seeing if the highest nibble is C. If so, then fall through to some low level code. lda $2000 <-- normal management spawn lda $c010 <-- oohh... jump to page $c0 code $c0 code would then check low byte and act accordingly. ed: well, that's similar to what I do; if the high nibble is C, then I look up the function to handle that address; on a NULL function, it just doesn't do much. it's the lookup that seems slow to me. Perhaps I'm just not enough 'C' literate to understand :) eolson- That's how I handle reads/writes for my emulator when dealing with screen page memory or Cx00 (65816 I know... C I fake.) it's only one instruction in 68K. **** Action : Saltine thinks the key to speed = lookup tables kevin- so it's an indexed jump? Not an actual search... okay :) so you can load the address up, then a BEQ takes you away to normal handling if the address was null... akin to: jmp ($table),y where y could be the high byte - $c0 kevinl - do you maintain a status register or create it when needed? ed: yeah...it's a flat array of addresses, not a list to search. Kevin do you have a table for all addresses or only C0xx? kevin- ooff.. I'm relieved :) saltine: well after math ops, I save the 68K status register and then refer to it later when it's needed. mike: just Cxxx now; the next rev will bbe more flexible (and allow >64K flat address space) kevin- Now, for display purposes (in text mode), the emulator needs to read page 4 itself and convert the ascii to a bitmap? (i've never really understood that.) ed: yeah, you got it, not much more to understand. kevin- okay... I kind of want to write an emulator. :) ed: I just have a bunch of little bitmaps of characters from which I construct a display...that's all... eoldon: don't even consider writing 6502 in C for any purpose but to learn! kevin- that makes sense. ed: yeah what saltine said. My first C approach was dog-slow... saltine- it'd be a good chance for me to learn C :) mine too eolson - I can send you some source to look at kevin- how big is the code for the 6502 emulator? saltine- if you would, i'd be greatful. ed: to get a feel for possible emulator architecture, you might want to consider doing an STM module... *** eolson is olso0...@dialup-1-60.gw.umn.edu (bryer) *** on channels: #emul *** on irc via server Charlottesville.VA.US.Undernet.org ([128.143.246.9] SuraNET server, Virginia) kevin- hehehe :) what did you have in mind? ed: whatever...what was your favorite Apple II peripheral? kevin- ummm.... hard drives :) kevin- for my emulator, I was thinking of throwing out the Disk II, and just settling for smartport emulation. A lot easier, and just as practical for newer software. comments? I threw together a timer this afternoon to automate those speed tests...fooling around with an ultraterm (videx) now. So emulate a hard drive...profile can't be too tough. ed: well, it depends on what you want to run on it. Kevin which speed tests? ed: a lot of copy-protected stuff does its own I/O, fastloaders too. kevin: i'm not concerned about DOS stuff.. :) ProDOS and GS/OS (hahaha!) would be fine. kevin- but they almost all go through smartport. My OS did. moke: somebody posted some benchmarks, will be posting revised ones in a couple days. Kevin yeah, the guy from cafe.net? I was just wondering because I put in an automated timer too :-) OS^2? Hehehe. Anyone ever heard of Syris Software (and the infamously slow KansasFest demos?) mike eolson : Yeah.... mike: I don't remember where he was from. maybe we should standardize the timers? kngfisher- that was my doing. :) eolson : I cannot figure out their OS though.... eolson : Yours ? kngfisher- yessir. eolson : EcoManics and Prince Cupric ? Kevin how does yours work? Mine is pretty simple... you enter the command and it presses spacebar for you, then sees how much time elapses until the program beeps. kngfisher- did you think your computer had crashed when it was decompressing all that stuff? ecomaniacs and prince cupric and KF94 demo all mine. all mine. mohahaha! eolson : Nope... I had a ZipGSX 9/32 in my machine... no problems waiting though.... kngfisher- I see who didn't pay their shareware :) mike: I made a card...writes to C0x0 start the timer; C0x1 stops it; then you can read elapsed time (in 60ths) out of those two locations. kngfishr- I got a bunch of complaints though... It was an excellent lossLESS sound compression routine though. eolson : Unfortunately, I din use them at all, took one look and deleted it. There were a few people who were going to join us and are not here... I hope didn't accidentally connect to EFnet. kngfishr- I know :) EcoManiacs was the only one worth a disk to store it on. eolson : The club's library still has a copy of it. kngfishr- really? wow... eolson : The club's PD library collection kngfishr- what club is that/ Kevin what cards do you currently emulate? mikeo: I am rcolbert - just on under a diff account **** Action : kngfishr the Apple IIGS Disk Librarian for Brisbane Apple Users Group. mike: the timer also puts a unique pattern in the card's prom space, so it can be detected. If we standardize (on it or something else), then it can be built into the benchmarks... kngfishr- neat. I thought everyone had dismissed those. (perhaps they still have :) You don't get a whole lot of requests, I imagine :) mike: well, lets see...language card, disk2, that's it (lots of other modules load to handle other stuff like paddles, video, sound, etc). Then there's the dumb timer-card, and I'm working on a videx ultraterm. eolson : Only a few of those die-hard ones..... not sure what they did with them though. eolson : I pity those who are having NON-accelerated GSes What I'd really like to do is add Thunderclock emulation. Does anyone have a ThunderClock ROM image or port info? kngfishr- no kidding. Slow compression routines or not :) yeah, if somebody would cough up specs on thundercards, I'd whip one up in a jiffy... eolson : I am not sure, one of these days I should pop out the disk and disable my ZipGSX mikeo, kevinl: I have an issue that I think needs to be discussed It has to do with standardizing the swapping of disks swapping = ? kevin- how about a way to *restart, not just reset the emulator? kevin: well, you know - when it is time to change a disk - you responded to a post about it recently ed: yeah, you, everybody else, and their brothers... kevin- c600 g doesn't always work. Maybe that's a GS thing. DUnno. It just doesn't work! oh yeah...well I just have a popup menu on the drive pictures.... salt: I think the issue was that changes to the image weren't saved unless explicitly requested... c600g is the machine language for Apple II. kevin: right, I think that just like a real disk, you should have a write protect c600g also can be used on the GS if the write protect is set - no update if it is not set - automatic update kngfishr- I'm exagurrating :) It just doesn't work on STM all the time :) I think that if the write protect is set you should get a write protect error, not just have your data disappear. salt: a write-protect check box would be cool...I also just need to have the drives ask the user to save or not... yah... I agree with Mike. eolson : Still, I think the BEST //e emulation for the Mac is the Apple IIe card for LC (except LC630) mikeo:good idea ed: you can now branch straight into C600 via the debugger window if things get hung up... kngfishr- you use a 6502 & mega 2, you typically get good emulation :) kevin- i've done that. Doesn' t doh! doesn't always work.... **** Action : kngfishr laughs ed: oh well, I guess I'll have to work at it then. If you can mail me the conditions where it locks up that bad, I'd appreciate it so I can duplicate it... mike, kevin: What would be nice is a disk format that contains a flag to show that the disk is protected or not Code you wouldn't be Jeff Miller would you? Saltine what I do is just treat a disk as write protected if the image is marked "read-only" no not me i'm starting a crusade to get kevin to port STM to powermac. it starts with everyone sending him money? :) Does Kevin have a PowerMac? mike- he doesn't need one! ;) anyway, saltine, you said there was a disk-swapping issue you wanted to discuss. Did we cover it, or was it something else? I very much do not have a powermac; I have a IIsi... has anyone seen any olympic decathlon images around... if so, does it work on the emus? Kind of tough to write PowerMAC assembly on a IIsi. Maybe next time I get my financial aid check a PPC version of STM will appear. kevinl: I think we touched on it - I have found that the Apple2000 is not very natural I would similarly like to get AppleWin up and running on the RISC platforms that NT supports... PowerPC, Alpha AXP, and MIPS. kevin- write a powermac emulator for the 68k first then. duh! kevinl: when it comes to swapping disks mike: well, I guess I could write it. Assembling it would be a different issue though... ha ha It should just be a recompile, but I don't have access to RISC machines to recompile on. yeah, so, like, the Apple II is cool. mikeo good point! so mike... tell me about compiling emulators. thanks kng Thanks... but just out of curiosity why did you make it so non-ops can't talk? hee hee no wonder munz is so quiet. *** Mode change "+o eolson" on channel #emul by kngfishr gee, thanks :) *** Mode change "+o Munz" on channel #emul by kngfishr saltine- I already forgot. Was it you that was gonna send me C source? MikeO - did you read my scroller on the boot disk? Eolson I am writing a compiling 65c02 emulator but am not done with it yet. eolson - yeah, what is your address Ed, please :) mike- how do you reconcile addresses? Two passes? all : Time for lunch *hungwee* see you all around later..... *eolson* olso0...@maroon.tc.umn.edu (or dcc, is good) Eolson I am not sure what you mean by reconciling addresses *** Signoff: kngfishr (Apple II Forever !!!!!!!!!) mike- if you recompile, then you get x86 code out the back end, right? Yeah mike: have you run applewin under win95 or nt? mike- how do you make sure that jmps and everthing corrospond correctly without 2 passes? eolson: the code will be in the mail - I'm on a telnet server :) Oh, the thing is that it doesn't try to turn the entire program at once into X86 code mike- and do you have 2 processes running, or one? saltine- thanks! *hungwee* hungwee? mikeo- That would be hard... Whenever the program jumps, it checks to see if the target address has been compiled, and if not, it compiles it and then jumps to the compiled code. mike- how do you determine how much to compile? Turning an entire program into X86 code at once would be almost impossible because most programs self-modify mike- looking for an rts? Eolson up to a potential branch mike: so, does it never interpret? mike- hmmmm... mike- is it really that much more efficient? Kevin the only thing is that right now AppleWin has two different interpretive emulators, one which is faster at banking and one which is faster at everything else Kevin when AppleWin is using the prototype compiling emulator, if the program starts doing a ton of banking then it will fall back on the banking version of the interpretive emulator mike: yeah, I'm wondering if your compilimg emulator ever interprets, or does it always compile a fragment first? mike: oh, ok Eolson the compiling emulator is faster, but not overwhelmingly so. However, as I add more optimizations, it will be. you know, we should make a lits of who has complete specs on what bits of hardware, so we can incorporate them into our emulations... (um, that's "make a list") I want to know why this channel is private... what if other people are trying to join? Does anyone know how to reset this channel to normal? like, for instance, I'd love specs on a 3.5" controller, or a graphics tables... "(um, graphics tablet) but I don't know anybody who has them... kevin- smart port? *** Mode change "-m" on channel #emul by CodeRippr ed: don't know what it is (my Apple II days ended around the time prodos came in) ed: except I know it's a protocol to access mass storage or something like that I'd love more info on AppleShare kevin- oh... It's a neat little SCSI like disk system... kevin- you pass block based commands and get entire blocks of data stored at any memory location. for instance: should be normal now jsr $c50d Thanks cr! ed: ah, so it could really rip if you had the OS handle it. dfb #$01 (read) dw parms cool...randy's here and your parms would have the block number, the address you want it read to, etc. Heys guys, sorry I'm late hi randy! Hi Mike ed: I see, it picks up a param block from your jump point? cool... oh, nd another thing... it's super fast. Emulation would be really handy. The ProDOS MLI uses it, so it would be 100% ProDOS compatable. Most pseudo-OS's even used it. kevin- it's really a neat trick. I think I missed this neat trick... mikeo: have you run applewin on 95 or nt yet? & have you tried using wing with your code? we should talk about disk images... it would be nice to have a central collection or something, but access would need to be restricted to keep it from being a circyus (believe me, I know...) ed: sounds nice... kevinl: i agree. c64s have em Code, I use Win95 and NT every day. I only boot into Win31 periodically to make sure I am still compatible. mikeo: any speed increases under 95 or nt? Code, I don't use WinG, but I do use CreateDIBSection() on Win95 and NT. That's the API that's behind WinG. Hi Doug! Hi Mike What are you guys talking? ctk: obsolete hardware brb.... Dr. Pepper break. heheh I should take a moment to introduce people... mikeo: how hard would it be to put WinG code so that Win 3.1 users could get the extra speed? what? obsolete hardware? apple ][ obsolete?!?!?! KevinL is the author of STM (for the Macintosh) Yes please do Mike **** Action : kevinL bows humbly Mark Munz is working on an emulator specifically to run AppleWorks on the Mac and later PC Mark, are you the author of AppleWorks? mikeO is the author of AppleWin (for Windows) i think mark did later versions of appleworks (or so i read) Thanks CR Doug Kwan is the author of YAE which runs on most UNIX platforms I'm back. :) I'm still trying to figure out this Homer package. :-) Randy Spurlock is the author of apl2em, which was one of the first ever Apple emulators. **** Action : CodeRippr modified an emulator called 6502 which no one has (anyone want it? :) One of the most out of date now it seems, nice to meet everyone! **** Action : kevinL wonders what coderippr means. hello, all... I'm just a wanna be "you guys" If there are any other authors here please speak up... the aliases can be a little confusing. **** Action : CodeRippr would never rip code :) I'm just a 65816 programmer. Looking for an excuse to leave my GS at home when I go to school :) eolson: programming games for SNES? Randy when did you write apl2em? doug- (hope that's your name) no... Offered once, but :) **** Action : Saltine has left the obligatory C emulator behind and embarked on a journey into Machine Language Hell! *** Mode change "+o eolson" on channel #emul by Munz munz- thanks :) welcome to hell, saltine. Mike: Back in 1988, geez 7 years already! I love assembly. eolson: yes, that my name. What did I do, I'm still trying to figure this stuff out. At least, I love 65k :) I'm not so sure about 60x :( doug- wanted to make sure :) Randy wow! I first saw it around '91. I thought it was cool but I didn't really have any disk images to use on it. Randy then around '93 images started showing up all over the net, and that's when I really got involved in Apple emulation. randy: whats the stats on the emulator? all: I need to leave for a couple of minutes, ba back soon randy: I remember downloading it and being amazed too! I'm working on the changes necessary to bring the emulator up to ][e i sent suggestions to randy awhile back and never heard a reply :( I remember d/ling STM .8something and thinking "this is really slow." (just kidding) Sorry CR, I've been a little busy lately and work always seems to go slowly hey if you thought it was slow, ed, that's ok... i grabbed stm and kept wishing for a pc emu that worked so well (ie AppleWin) randy- I think I even have your emulator sitting around here somewhere (on the good ol' 286 :) kevin- actually, I'm really impressed with .881! thanks ed, I'm blushing. When I initially released it I gots lots of messages from all over the world Randy I met a co-worker of yours named Scott at a recent convention and we talked a lot about Apple emulation and apl2em. kevinl: Ed, I'm really impressed with all your wonderful GS programs! Wish I had a MAC kevin so I could see your emulator mikeO: (just being nosy) what do you do for a living? Scott ? ed, sorry I dodn't know you had any! I'm sure they're most impressive... Kevin I'd like to see your emulator too; maybe you could upload a screen shot? stm is really nice, but needs a fast mac psssttt... kevin- change the speed graph to make it look really fast :) oh sure, I could snap one....I don't know if I can fit all the windows on my monitor at once though! "Yah, this was on my Mac SE.. Yah." Kevin - Me too: i tried to run it on my Mac emul but it wanted Sys 7 or something Randy sorry I forget his last name but I remember his e-mail address is sco...@bangate.compaq.com. He works on ProLiant server monitoring tools. Mac+softwindows+linux+apl2em Saltine - it's easier to write for Sys 7 :-) yuck :) I'll have to look the nickname up, drawing a complete blank for now CR I write train dispatching software for Windows NT for a living. You guys already agree on standard disk formats? I'm still toolbox impaired from my "tool-free" up bringing. randy- yes... we're encrypting them with triple DES now. :) heheh randys: I'm trying to get them to agree on nibble images :) Don't expect support from my emulator anytime soon then ;) Saltine I don't think that everyone here is familiar with your complaints about current disk images so perhaps you could explain them. Saltine: Compressed nibble images I hope... mike- lack of support for copy-protected programs? mikeo: Well, I talked to kevin, but nibble images need track lengths for each track I like straight data images. Randy actually nibble images are the easiest to support; you just bypass your nibblizing and denibblizing functions. But I'm thinking 3.5" disks. I don't know anything about 5.25" :) salt: yeah, it needs some sys. 7 support (well, id shouldn't *need* them, but I'm too lazy to check for 'em and use them anyway. anyway, back to the disk images.. I'm willing to put up the server space if we want to make a comprehensive set... but I tried it before, with open access, and just about got nuked. hi I'm back. I want to ask if we need to standardize image format? doug: I think the .DSK is pretty much the de-facto standard, unless we want to standardize a nibbleized one. (which would be a good thing to do) But nibbles take up a lot of space Right, but how do you support variable length tracks, quarter and half tracks, etc? If there's interest, I can post the format I use for nibbleized images, see if people like it... doug: yeah, they do, but sometimes it's the only way to go... randy: my format tracks (ha) track length and 1/4 track position per track... Can we design a new format? kevin: Sounds good, can you post the format somewhere? Well, before we go much further, I would like to get my program that allows me to trasfer protected disks But we need to think about it clearly before setting the standard randy: sure...it's real simple. Now what would be very cool would be an Apple II program that reads a raw track... then transfers it to (whatever), along with track-sync information. Not really, you need to idenfity the sync nibbles kevinl: I HAVE IT! someone kill coderippr plz Sorry but I think I may be the only one here who has *never* actually owned an Apple ][ before, in other words I can't help there If we're going to have a standard header at the start of disk images, I think the first 128 bytes of it should be a MacBinary header, to head off the endless questions from people who need to convert to/from MacBinary Saltine: does you program reads sync nibbles also? kevinl: it is called SST (Saltine's Super Transcopy) ctkwan: My program is a modified EDD IV - it reads EVERYTHING randy: if you never owned an apple ][, what made you want to write an emulator? mike- no! no! no! mike- StuffIt Expander will automatically strip it! mikeo: it wouldn't help...when somebody uploaded it, another 128-byte header would get tacked on. Umm why did we just go private? mikeO: or make emulators automatically detect the extra 128 bytes doh! mike: How about skipping empty sectors? A lot of disk images contain empty sectors. sorry :) mike: what would help would be if PC emulators checked image size, and skiped 128 bytes if appropriate. CR; Someone else here at COMPAQ said that THEY could write the fastest Apple ][ emulator, after that the race was on! oh yeah, what CR said. Ctkwan I agree, or add run length compression so that they would get mostly taken out. MikeO: Apple2000 also supports DDD files - saves a ton of space randys: hahahah cr: why not we use a standard header. Just make PC and Unix reads MacBin headers. mikeO: also makes it easy to transfer disks randys: you've got a great asm coding style! i could NEVER be so organized :) .DDD is a bad suffix. It's reminiscent of Disk Disintengrator Deluxe. Hi lothoes. ok, how does this sound - a mini-header for each ttack, with a data type coud; it could be straight data (sector dump), nibbleized, compressed nimmleized, etc., and mixed within an image. CR: Blush...thanks eolson: it IS Disk Disintegrator Deluxe! it is? ummm... oh. do macbinary headers include the full original filename in them? man, I can't type to save my life today, sorry. cr: yeah. Yes, sounds good I would rather see any header information all up front instead of being at the start of each track Hiall. so with sucha format, if a protected disk just has one special track, only it needs to be in nib. format. kevinl: that would be good, so we dont have applekong.sit and akong.zip er, applekong.dsk and akong.dsk Did I actually managed to make it this time? *** Lothos is now known as Alex Hi Mark cr well the whole akong.dsk problem is about to take care of itself because Win95 (and the version of DOS it includes) support long file names mike: sure, you could just pile the headers all at the front...more of a file directory, then. **** Action : CR (dreaming) some day all os's will support more than 8 characters I doubt this. We are still using an OS developed in 70's for workstations and a CPM clone for the PC :) Kevin one important reason to have all header info up front is that if you compress tracks, you don't want to be walking header chains to find a certain track Excuse me for a minute, I have to put my kids to bed, I'll be back... saltine- what's sst? saltine: how big is it? Justa disk image? kevin: yes, just a disk image For that matter if you compress tracks you're not necessarily going to have tracks in any special order, because as a track size changes you'll stick it wherever it will best fit **** Action : eolson realizes you guys caught a different part of the A2 generation :) **** Action : CR (lurking) where can i find an olympic decathlon image? mike: ouch! Why not buffer the whole thing in ram, the re-write it when the user's done? Images aren't all that big... Kevin well you could certainly do that but I guess I don't really see the problem with having tracks out of order. kevin- I agree... cr: yes, we have plenty of memory these days. Just suck the disk into RAM. saltine: well you could mail it out, but that's a pain... mike: me neither, but it seems like a hassle to re-compress a track then look for a hole in the file to stick it back into... Anyway speak for yourselves about having plenty of RAM... what about poor Randy who only has 640k :-) kevinl: to use, you need to be able to tranfer from image -> real Apple // disk it's not too much for an emulator to ask for 4MB. saltine: oh yeah, duh, I feel dumb now... STM doesn't even use that, does it? For PC's how about putting new tracks that do not fit into empty space at the end of the images and then do a "pack" off-line? eolson - wow you can require as much as 4MB? ed: runs in 3 megs if you only have one image loaded; 3.1 for two; if you want to run ultima V and configure 8 floppies, who knows? **** Action : Saltine thinks that anyone who writes an emul is NOT dumb saltine: would you settle for foolish? I guess it's time to port to Watcom, protected mode Hmm you know I have plenty of RAM in Windows too but I guess I'm still not seeing your problem. If you have a header that contains an offset and length for each track then you should be able to stick them any where you feel like it randy: have you looked at djgpp? mmunz- figure a GS with 2MB ram (minimum!) 1MB emulator software itself, 1MB disk cached stuff? kevin, mike: would you consider using .ddd images? I have ALL of my images in that format and it is a pain to convert to .dsk it's not that outrageous. Look at Microsoft Word! It takes... what... 5MB ram, and all it does is let you type. An Apple II lets you type and play old games! What more can you ask!?!?! Saltine I really don't know anything about DDD daltons! mike: maybe we're thinking different things...it sounded like you were suggesting that if most of the image was on disk but you had one track in ram (or some tracks), and then re-compressed, you'd want to find an unused bit og the image file to stick it mikeo: I could get you the algorithm Well yeah I know what it stands for but I don't have any specs on it or anything back into...sounds to me like more trouble than it's worth Saltine ok I would appreciate that but out-of-order tracks, I have no problem with that... Sorry CR still working on the kids, no I haven't used the GNU stuff saltine: what does a DDD image look like? Get me the specs and I'll implement it if it looks reasonable. GNU kids? not familiar with that tool ;) saltine: can you post the DDD spec? ed: doesn't MS word let you load external modules now? I'm thinking Apple II emulation running in your document... I'm interested in finding out specifics about the DDD image too. kevinl: Kevin Kralian ripped it from DDD, I'm sure he will give me the code kevin- hehe :) Count me in on the DDD spec. Hey Alex, I didn't even see you come in! (Well I saw, but didn't know who Lothos was :-) ddd specs were never published - youd prob have to rip the ddd prog kevin: what's it like running an emulator in MS Word? Embed a game in a term-report? :) Mike: I'm still trying to remember how to use IRC :-) kevinl: The apple2000 loads all images into RAM and saves them to disks when you are done. doug: sure, the magic of Microsoft knmows no bounds! For those of you who xdon't know, Alex is the FAQ maintainer CR: The algorithm is implemented in Apple2000. gosh... 3.5" disks are so much easier :) Alex by the way what ever happened to the old FAQ maintainer James Vera salt: whoa! was it ripped? or are there specs out there? and just who was dalton? :) Mike: I don't know. When I started the FAQ I never intended it as a replacement for the earlier FAQ (which was more PC based anyway). CR: Kevin Kralian sat down one day and figured the code out! Alex I think the two FAQs would be complementary, because his has answers to all the newbie questions while yours has a more complete database of information. salt: sweet *** mike_ is now known as apples Kevin: Do you know when you'll be able to support monochrome macs? Anyone else trying to use an internal 6502 debugger to find emulation problems? Alex by the way who is this Teodor Angeloff that's mentioned in your latest FAQ? Randys yeah I do that too. kev: any chances of the stm image site going back up, or are you fed up? apples: well, someday...the last rework of the video code was done by Jim Nitchals, and he keeps saying he'll do it one day... randy: yeah, I put a debugger in the latest STM Mike: Yeah, I was more interested in the emulators :-) cr: not back up on a public basis... I'm thinking of implementing an instruction trace buffer so I can see what happened, AFTER it's happened. kev: uh huh... kevin: Hope so... since it'll be at least another year before I get a color-capable Powerbook :P randy: good idea...I was considering an option to log the instruction stream. Randy I have something that dumps trace to a text file **** Action : CR toys with the idea of putting up an ae or catfur site :) What kind of features are in the current debuggers? Randy the only problem is it's absolutely huge.. you get 20 megs of text just booting DOS brb... when I debug my compiler, I ran another 6502 emulator in parallel and compare the two. Mark: What about Phoenix... does it work on monochromes? BTW guys, I'm captureing the whole thing - will edit it and post it! saltine- good idea! randy: um, in mine you can modify registers + pc, set breakpoints, trace, step, etc. randy: it gives a window that looks like the II monitor disassembly. kevin: Can you set breakpoints in ROM and self-modifying code? randy: and lets you edit any number on the window, including the opcodes **** Action : Saltine thinks kevin did that so he can have unlimited lives on Hard Hat Mack MMunz, are you there? PHoenix works on 68020 Macs, Monochrome and color randy: rom yes, self-modifying, no...it overwrites the BRK I stick in. Same basic stuff here... Randy you can look in the AppleWin help file for a list of debugger commands, it's under "using the debugger", "debugger commands" saltine hehehe! kelvin: how do you do breakpoints? Do you check it for every instruction? MMunz: oh, sorry... must be lag.... thanks for the info! I support two kinds of breakpoints, soft and hard. ctk: I put in BRKs, and keep a list of locations that have breakpoints; when the emulator hits a BRK it looks up the address... ctk: if it was a breakpoinnt, it halts, and if wasn't, it executes it as a BRK. mmunz: where can I get Phoenix (gotta try it on my Mac emulator :^) The way I handle breakpoints is that when you type "G" for go, it runs in a different mode where it checks every memory access. so you save the old instruction The soft breakpoints are implemented via the BRK opcode while the hard breakpoints I actually check the PC value every instruction ctk: yeah, I save it, and then use it so that you don't see the BRK in the debugger. That way you can breakpoint on things like variable use or I/O ports, which is nice. mike: sounds flexible...but slow... mikeo: Yeah, I also have data breakpoints, read/write and access Saltine: Phoenix II (the code name) is to be published this summer. But Phoenix II isn't a pure Apple II emulator. can be use a bit map for breakpoints? Munz- is Phoenix fat? munz: are you licensing the roms from apple? Saltine: Phoenix is designed to run AppleWorks 5.0 and true Apple II speeds. mmunz: oh, the Appleworks emulator Do most of the debuggers use the standard memory access when modifying memory so that you can change soft switches just be editing memory? doug: use a bitmap how? randy yeah eolson: Phoenix is fat - I'm using CodeWarrior to develop it. no, I don't support break point but I think using a 8K bitmap CodeWarrior rocks! :) randy: I ignore hooked I/O locations in the debugger; otherwise, the scrren and speaker would go nuts anytime you scrolled the window by 'em! for breakpts is fast and it uses only a little memory. Reasonable? MMunz: You mean it's just going to run AppleWorks, and nothing else? kevin: I just don't dump memory at those locations :) ctk: you'd still have to check the bitmap every instruction...faster to use a byte map, but still slow. randy: yeah, that works... Randy my debugger doesn't use standard memory accesses when updating its screen, though, so for example it won't trigger soft switches just by paging up the code display through C0xx the problem with using I/O routines in a debugger is that looking at a location can change its value... mikeo: is there a debug command to display the current Apple screen? kelvin: but only one check is required for multiple breakpts. so you'd need...a heisendebugger. Randy yes, it's \ Randy the reason it's not listed in the command list is that I was having trouble making a Windows Help topic of "\" :-) ctk: inserting a BRK, though, means you do zero checks for multiple breakpints...can't do self-modifying code, though... mikeo: I know all about windows help files! kevinl: Thats why I support two different breakpoint types, one is faster than the other but less flexible I basically use the same command set as SymDeb, CodeView, and SoftICE, which is why some of the commands have weird names (like "MDC" and "\") apples: Right now, it is only going to run AppleWorks. It's a tight integration of Apple II to the Mac. It reads files (not images) ala PC Exchange and can move data between the AppleWorks and Mac clipboard. randy: well, that's a good idea. I have a trace mode, so maybe next time around I'll toss in soft breaks... kevinl: What is tace mode? kelvin: besides self-modifying code, it also does not work for jumps into middle of instructions. Sorry...trace randy: like automatic stepping...the debugger window animates and follows the PC through memory. randy: basically, it auto-scrolls to the PC every time it leaves the window. Mmunz: Will Phoenix run on monchrome Macs? Oh, I support that too, you can single step or step x times. MMunz: I see... AppleWorks for the Macintosh, basically :) Alex I sense a new entry in your FAQ database :-) Alex: Do you mean SE's or B&W screens? Mike: Ha ha :-) I also support a Proceed command that processes any subroutine calls randy: so if I understand the soft-break idea, you're basically single-stepping while watching for a condition? will phoenix include appleworks? Mmunz: B&W I guess. randy: ah, so like putting a break on every RTS? (conceptually, not in reality) kevinl: No the soft break inserts a BRK opcode into the code so it doesn't work for ROM code, self-modifying code, jumps to mid instruction points, etc. seems to me thath if you have a routine modify your op lookup table, you can point all ops to a break w/o side effect!? CR: JEM Software (who's the publisher) is working a deal with Qualty - so we can provide those with AppleWorks 5 and those without. kevin: Yes for the procedd, nice for tracing through code mmunz: you mentioned you re-implemented some of the ProDOS stuff in native codes. How do you dispatch these routines? Check for every JSR to these or just patch Applework? Alex: B&W is supported (and is actually a little faster). Color is cooler, since you can change the foreground/background colors :) Saltine: Yes I have been thinking about adding that as a third type of breakpoint *** Signoff: Yakumo (Error 0) MMunz: Great! B&W rules! randys: it could be used for a trace mode too Randy when you were racing to see who could write the fastest Apple II emulator, did the other guy ever finish his? saltine: yeah, I just haven't done it yet...break on a CLC would have been cool for cracking games, way back.... alex: but it's better to have colours when play games. ctkwan: I originally checked the locations. But then figured out that since AppleWorks is 65c02 code, I could use (abuse) an unused opcode to talk to the emulator from an Apple II program. Yes but he never released it, it only works on a 386 with a VGA and a 101 key keyboard. It still has several bugs also munz: so what sort of deal are you making with Apple for the roms? You're not gonna get an exclusive license and persecute us all are you? tisk tisk tisk, Munz :) Randy do you know who wrote applemu? randys: doesnt seem like extreme requirements kevinL: No deal - because we only do AppleWorks, there is no Apple ROM's that are used. Hey, I have Laser 128 ROMs - so apple can go to heck! (oops - is should be are) Doug: You're talking to someone whose STILL using his original Apple ][ monochrome monitor on his terminal computer :-) munz: I have a "special" CPU mode where I also "abuse" a 65c02 opcode to allow the emumulator to execute native Intel code...ug salt: cool! munz: oh, that's a nice way to go, then...no controller proms either, I suppose.... mmunz: interesting. mikeo: No I have it but I don't know who wrote it....sorry randy: oh, and to think I looked up to you... alex: are you using an Apple ][ right now? randys: so when can we expect to see the next upgrade? randys: We've created extensions (Ultra commands) that let you play Mac sounds, change the window position of the emulator as well as screen colors and more. Doug: Amigas make great terminals :-) Sorry kevin, didn't mean to dissappoint you Randy oh well, if you're going to start working on apl2em again then we can have a competition to see who can make their emulator fastest randys: One guy is looking to create an external that will let you use the Speech Manager to read your AppleWorks documents. alex: ha ha I though you're using proterm. alex: I don't know how to take that :^/ It;s ok randy, I'll get over it. An APple emulator trapping into intel code...good heavens. Some things were not meant for man to do! mikeo: I hear you have a really fast CPU, mind sharing some tricks on how you do it? kevin- ditto :) Saltine: No offense, I like the Amiga (but mine's only an A500) :-( oh no Mike, pleeease! Let's not get into a speed war! hehehe :-) kevinl: I meant to use it to help transfer files to/from the PC Yeah - speed wars would be bad. It's great to see this kind of sharing that makes all the emulators better. Randy well it's 32-bit ASM, and also I spend a ton of time optimizing it, especially with respect to Pentium U/V pipelining I've learned a lot of new tricks that will help me with version 2.0!! Come on I wasn't suggesting a war or anything, I just enjoy friendly competition munz: Neat, wish I had gotten around to doing my extentions, maybe later... hey, here's something I did, possibly everybody does it, but I'll toss it out just in case... may be we should make an FAQ for emulator writers too. mikeo: You been reading too much Abrash... I use a 16-bit dispatch table, which lets you rip through common instruction pairs... You know, it'r really neat if you think about what emulation does - it lets all of us use the same programs across many different platforms like DEX/BNE for instance... or ASL/ASL kevin- interesting... hadn't thought of it... Kevin yeah that's a good idea kevin- are you doing that in STM? Kevin, I don't quite understand kevin: Neat I don't use a dispatch table now but I think I'm going to change to use one kevin: how effective is this trick? The only problem is I have been learning some hard lessons about the importance of keeping things small :-( kevinl: Kevink does the same on Apple2000 you can really go nuts with something liek a dex/bne...just fetch the next byte, multiply it by the DEX/Bc count, and move along. I skipped that, though, cause it felt cheesy. oh wait... doesn't that have problems? You would have to disassemble two lines ahead and make sure both commands are single bytes... mikeo: Been thrashing the internal cache ago....naughty naughty.. I made a cool optimization to the IND,X addressing mode code the other day, which saved two cycles but added a byte, and it ended up making the emulator *slower* doug: I don't recall...it was a significant speed boost. I could still bring out more speed by implementing more instruction pairs, but I'm lazy at heart. ed: well, that's what the lookup table is for. kevin: I will try this trick later. kevinl: do you have a single feetch cal each opcode? ctk: well, good luck. But I'd like to exact a pledge from everybody here... mike: tell us more please kevinL- how is it set up, exactly? If you have NOP NOP ($eaea) what do you do? to not disassemble the new benchmarks and tune in instruction pairs to blaze through them, but nothing else... eolson: nothing :) please? ed: add two to the PC and continue... ed: and 4 cycles, or whatever. kevin: Oh geez, another Winmark.... Doug well it's just that code size is extremely important because you want all of your common instructions to fit in the processor's internal cache kevinl- well, yes... that's the obvious answer :) What I mean is how is it looke dup and dispatched? (NOP NOP was a bad example :) salt: a single fetch whenever I'm out of opcodes... ed: well, you just have this array of 65536 function pointers... reference the $eaea'th, and see if there's an address there? mikeo: Did you arrange your instruction code to have the most common instructions grouped together? ed: any pair that's not implemented just points to the handler for the first byte of the instruction kevinl: Apple2000 has the fetch routine at the end of each opcode, eliminates jsr/rts kevinL - okay... I'm feeling stupid. I get it :) Randy yes I actually did that just recently; it adds about 5% speed kevin: did you do some statistics on insturction pairs? I suppose you have codes for some specify i/pairs. How did you pick them? salt: yeah, I do the same thing. Does everyone else do that too? ctk: I have no such stats. Wish I did. Jim Nitchals mainly picked the pairs to code up. ctk: I've been considering tracing a boot, maybe some choplifter, then analyzing the instruction stream. But did I mention that I'm lazy? kevin: how jumps (bxx,jsr,jmp...) are handled? kevinl: you could modify your emul to keep statistics and run a game for a while, then look at theresults bxx? ummm... mikeo: My current version of the emulator has the opcode laid out on 64 byte boundaries, I just fetch the next opcode, shift it, and jump to that address, the fetch code is at the end of each instruction code ctk: well, if you have a Bxx, you already have the displacement loaded into the low byte of the word you fetched, so you're set... what on earth is bxx? ed: branch instructions (BCC, BVS, etc) is that some sort of arcane way of saying a generic branch? thank god... thought I had missed a branch type :) Randy have you done any speed comparison between that way and the jump table way? branch on xerox xenophobes. I dunno. kevin: I did that a long time ago but I lost the data. There are problem in doing stats. To begin with, we need to skip the boot codes. doug: unless you want a real fast boot! hee hee mikeo: The jump to aligned opcode code is slightly faster than a jump table on a 486, but I don't know about a pentium, It has a seperate code cache all: anybody consider supporting single files? Apple2000 does, and once again, it saves space That would solve your boot code problem with stats too salt: single files? what do you mean? Saltine: Single files, you mean like an Apple ][ harddisk? kevinl: well, you rip the file off of an image, and then store it on any media kevin: For games, I remember that STA (zp),Y type of instructions are the most common, how do you guys handle the indirect mode. It's slow. the instructions I used most often in my programing were STA [zp],y and the sta (zp),y they were super handy for games. doug: um, couldn't tell you offhand (I wrote the addressing modes about a year ago, hardly touched em since). I could look up the code if you're really interested. just a binary file off of an Apple disk will load and execute immediately Salt: Phoenix actually reads the native disk (when a directory is read, it "looks" like an Apple HD). I wish I could find more information about Apple ][ harddisks salt: nope...but STM does have a save-state command, which queries all the modules for their state information and saves it, so you could kinda do it that way (oh yeah, you can restore it too) ealson: sta [zp],y ?? are you talking about 65816? Salt: How does A2000 work with a game which is split into two or three parts (like "Wavy Navy")? doug- yes... sorry :) mmunz: this is strictly for games though, since the Apple had a LOT of single file games that never accessed the disk doug- it takes a 3 byte pointer. Super handy. alex: you would then have to use a disk image. doug- for graphics, for instance. a bunch of lda(icon),y sta(screen),y could od the trick really elegantly. (albeit slowly) Randy hmm OK you do xor ax,ax; mov al,[si]; shr al,6; inc si; jmp ax? eolson: but it is slow for emulator, as least for mine. I need to check for side-effects because indirect addressing mode can touch I/O locations or write to a protected memory page. Is byte swapping at issue for any of the emulators? As in reading lda $2324.. mikeo: shl actually and I have to use an index to jump, real mode you know doug- you don't use a generic memory i/o handler? has anybody here seriously onsidered using a real MMU to implement I/O traps, banking, etc.? What I do is basically xor eax,eax; mov al,[esi]; inc si; mov eax,[opcodetable+eax*4], jmp eax Randy oops I meant shl! :) munz: nah, one instruction, six cycles max, reverses the bytes on a 68K Randy so it's really the same number of instructions. The advantage of your way is that it avoids an AGI on the jump. kevinl: Not on an ntel platform, handling the fault would eat a lot of time eolson: I use pointers to memory pages. If the pointer is null for a page, I call a memory routine, in this way I don't need to call a function for non I/O locations. mikeo: You have been reading Abrash, go ahead, admit it, and yes it does avoid yeah, ror.w #8, dn, if I recall... the AGI, but it didn't start out to do that doug- okay... so why is it slow? Just derefrence it and do it.... I must be missing something. Randy heheh, Ok now that you've accused me of reading Abrash you're going to have to explain about Abrash to me. randy: ok, slow for an I/O trap, but you could do page translation with it to handle //e-type memory banking. Maybe... ctk: ooh, I like that . I think I'm using functions for regular storage handling as well. Although that could be useful if I start compiling code. ********* Note: Lost connection to IRC - 3-5 minutes missing ********** kevin: available fro release. Too messy. hehe doug- hmmm... I don't know enough about compiling emulators :( randy: well, I don't know how it's shake out. It'd be a big savings on every memory access (emulated memory access) to not have to check paging tables. I just don't know what kind of hit it is to reload them. Randy I got most of my info from Intel's OPT32 document, and from experimenting (because Intel is not always correct) mikeo: He covers a lot of things Intel doesn't tell, and some things that were documented wrong, it's a pretty good book, I reccomend it. I'm losing conciousness :( **** Action : eolson yawns **** Action : kevinL thows a bucket of water on ed mike: you mentioned you are working on a compiler too. How's it going? I'm wet. and I'm losing conciousness. :) mikeo: He includes a timer program that will actually time the instruction sequences to see what the performance is. I'm glad to see that everyone here is into optimization, because I get some letters from people who think none of us give a damn about speed eolson: compiling emulators is not that sophisticated. You can read an article on the 68K emulator develop by ardi and get some ideas. Randy yeah I wrote one of those :-) I don't give a damn about speed :) Not with my future emulator attempt ... mike: the problem is, you have Apple running a 68K interpreter on, like, a 66 mhz box and gettinf the performance of a ~20-25 mhz mac... mikeo: You should have released with the control speed option OFF ;) mike: and then, for instance, STM only shows about 3 mhz performance on a 25 mhz mac... Randy I know! I'm definately going to talk about the control speed option in the README file next time. kevin- I'm not getting 3mhz on my powermac... I'm lucky to get just over 1mhz. kevin- and at that, the screen refreshes are ugly and torn. ed: yeah, I mean it gets 3 mhz on a real 25 mhz 040 mac kevinL: But Apple uses some tricks to get that performance. Like taking the most called routines and making them native. That's how I got my performance. ed: with ten clean refreshes per second, even Randy here is something funny I found (and still don't have an explanation for) while doing timing tests on my pentium kevin- that's why you should make a powermac version :) munz: yeah...but explain it to people who ask why the emulator's so slow... munz: Thats where those "abused" opcode come in really handy! ed: I'm taking donations... randys: You bet!! kevin- I'll donate my spleen. The loop "dec ecx; jne" takes about 1800 ms to execute 1000000h times *********** Note: Lost connection again :( missing about 3-5 minutes ******** munz: I'll bet more than 2-3x...but I'd be happy with that, though. A 3x per megahertz would give a 36 Mhz Apple II on an 8100/110! Ok good question, do you guys want to do this on a semi-regular basis? mike- quarterly, maybe? yeah, ed, lets do it again. we still don't have a disk archive worked out... doug: yes (it's past my bed time!) Sure, I am working on a collection of disk images. I've got quite a collection (in ddd format) Saltine: Any way to convert those, or get the format kevinL: I'm still learning about the PPC, so I don't even have any real optimizations randy: ive got a decent collection... i can mail you the list randys: I have to load em into Apple2000 and save them as .dsk (a pain) salt: id be willing to write to write a converter if you get me that ddd code crap-a-munga, randy! Saltine: Is that the emulator for Amiga? randys: yes cr: I will try to talk the author into giving me the code Saltine: We have some of the guys from the 'ol Commodore group here They have Amiga's and I might be able to convince them to help me out if we can arrange to get the DDD images randys: just like old times! okay... so post when the next meeting is, okay? :) I've gotta read 1984 for tomorrow. :( randy: do you have a list available? ok, bye eolson! randys: Apple2000 requires 020 + see ya, ed nice meeting you all... I'm inspired to write an emulator now! later... bye eolson, will send code! *** eolson has left channel #emul CR: No but I can put one together, I'm getting about 15Mb more images in a week or two and then I will put together a list randy: whoa... i have about 8MB now Saltine: That shouldn't be a problem I've got to go as well - this emulator stuff is much more fun than I originally thought it would be. See you guys later. bye munz Most of the people here are authors... we could talk about private archive sites except this is being recorded Bye Mike randy: still have it, I think. bye mark! mikeo: msg to everyone? *** Signoff: MMunz (PowerMac - the fastest way to run AppleWorks!) ********** OOOOPPPPS! Lost connection again ;^) ******************** mikeo: how about .sfg (single file game) mikeo: # characters is kinda limiting Kevin yeah I do that mike: how about .ap2, we are not limiting this to games only Hmm I like .ap2 I'll third that! .sfp (Single file program?) And when we develop our cool new disk image format, we can call it .ds2, for Disk ][ How about a poll in comp.emulator.apple2 ?? :) kevinl: not sure if I understand you Sorry but I like things like .do (Dos order), .po (ProDos order), etc. ack! no comittees! kevinl: Agreed! Hey, I liked .dsk (C64 and Spectrum don't use .dsk anyway). saltine: if somebody in a DOS situation tries to load a .sfp file with a macbinary header, you can tell because the initial length bytes in the .sfp shit! I forgot to turn the capture back on ! Can you retype everything for the last 2 minutes :) file won't match up with the observed file length on the disk... so if that happens, you can check for the address/length bytes 128 bytes later on in the file and see if that works... It's actually pretty easy to detect a MacBinary header randys: actually I don't really like the idea of .do and .po thing. We should use one single sector order to avoid troubles. We could still use the .dsk for emulators that auto-detect, but there should be a default type for it if detection fails Well if we make a new file format it should have things like sector ordering and data versus nibbles specified in the header hee hee, you could have different sector orderings by track... well, the first thing in a sector-type track could be 16 bytes giving the sector mapping order... doug: Can you always auto-detect the type correctly or you pushing for a new format that specifies all that stuff kevin: ha ha Well I guess the other thing to consider is, how much software really exists in .ap2 format right now? kevinl: don't laugh, some copy protections did have different sector ordering! If there is none yet, then we are pretty much free to define the format any way we want, so we can add a signature or something at the beginning. I prefer a new format MikeO: I don't think there is anything out there right now! If we could agreed on one we could do a conversion program to put all the images into that format! Ok so let's add a signature to make it easier to deal with things like MacBinary headers I think that Wings of Fury .nib file I sent you was the first copy protected image! Saltine by the way did you see my post about WoF? That function was NOP'd out in the version you sent as well! saltine: does DDD preserve relative positional information for tracks? Anyone knows about the .nib format? Does it record the leading zeros before sync nibbles? kevinL: yes it does kevinl: it even preservs two sync bits, but I dont think your nibble images do salt: Does DDD handles half and quarter tracks also? saltine: can it successfully encode a spiro-disk? ctkwan, kevin: yes Doug there are only a few images in .nib format right now; they have tracks that are 6656 nibbles (bytes) long and the emulator can pretty much ignore what's inside. Sorry, not DDD, EDD Another thing I worry about is people FTP'ing images without setting binary mode. If we have a signature it should be designed to corrupt to a known value during an ASCII transfer oh, what does the E stand for? EDD, Essential Data Duplicator? SST=modified EDD ctkwan: yes I obtained the source and modified it! mike: yeah, good idea; just alternate high bits on and off or something... The corruption is system dependant oh, and have cr's and lf's to see if they got messed with... doug: Could we just check for several possible corruptions? Well there are two kinds of corruption I think; loss of high bits and conversion of carriage returns randys: can be done, I guess. Or we could have two DWORD signatures at the beginning; the first one would be uncorruptable and would identify it as a disk image. The second would be highly corruptable; if the emulator saw that the first DWORD was right and the Way out in left field, anyone else going to the Computer Game Developers Conference this Saturday? can we check the length, this kind of corruption usually change the length of a file. second one wasn't, it would tell you what went wrong. randy: I wish! I wish too Randy do you develop computer games? I'll be happy to give you guys a report on what I see. mikeo: I wish, I'm going out to see who is developing for the Win95 platform randys: please do. Randy I would like that, especially if they have new info on DCI oh, yeah, see if you can pick up any books on compiling emulators... We develop Windows Display Drivers mikeo: MicroSoft is a sponser of the CGDC and they are going to announce DCI 2.0 kevin: is there any? I don't even find book on emulators. Randy cool I'll look forward to hearing from you about it. They are also holding a one day seminar on the Win 95 Game Development Platform. They are going to announce the new 3d API well not as far as I know, doug...that was just a joke... the new Direct Sound API, DCI 2.0, and they are going to give out beta copies of the tools and I'm not going to be there :-( MikeO: There is 1 compiling emulator for the Amiga, it is a PC emulator and takes massive amounts of memory, but is pretty fast Sound interesting and I wish I could go there but.... where is this conference randy? mikeo: Sorry Mike, I would like to meet you. kevin: In Santa Clara, at the Westin Hotel. salt: Are you talking about SoftPC from Insignia? By the ay, just for reference, where is everyone from? Irvine CA ctkwan: no, thats for Mac, this is PCTask University of Hong Kong, Hong Kong ah, that's close by where I live...what are the reg. fees? randys: Omaha Nebraska doug, isn't it afternoon there? Randy in Houston TX oh, I'm from Riverside, CA (well, not "from", but that's where I live now) kevin: The conference is full, but registration was $695 salt: there are other versions of SoftPC. There is one of Sun, I think. randy: oh well, so much for that idea. kevin: How close are you, maybe we could meet for dinner or something? randy: well not that close...near LA. Well let's formalize the .ap2 thing kevin: Opps we maybe next time. um, ap2 == single-file image? Yeah mikeo: You going to work up the spec? All we really need is a small header followed by the image mikeo: Sorry I thought you were talking about new image format mikeo: Right, simple for single file format in fact, I'm not really sure we need any header on the single-file program deal... Ok how about two DWORD signatures, WORD address, WORD length, and then another DWORD reserved to make the header an even 16 bytes Sounds good to me, keep it simple mikeo: You and I have been living in the DOS world for toooo long ;) yeah, simple - I have to convert all of mine :) Kevin well we need the addr and len for sure; I think putting on signatures is a good idea mike: what do we put in the header, length, load address, starting address, name (a long name) and what else?? Randy well, addr and len are there already; they're the first four bytes of the file... we can spot corruption just by looking at the image... right, and in lo,hi byte format if every cr is followed by a lf, we know what went wrong...if all the high bits are stripped, we know what went wrong... Doug I don't really think we should put in internal long file names because once all the OS's support long file names, having a second name gets confusing starting address? doug: it's in the file already Ok for signatures how about AP20 for the uncorruptable one and $80 $13 $26 $10 for the highly corruptable one Saltine: Do you already have some single file programs? randys: a bunch, yes kevin: no, some program cannot be run simply by "brun", you need to "bload" it and then run it at an address other that the first byte. but we can patch them. doug: well, you could always solve that by making the file a little longer, make it load a little lower, and tacking a JMP onto the front. But a head is a little simpler than that... ctkwan: yea, they can be patched Saltine since you already have some let's reverse the order of the reserved DWORD so that you just have to tack on 12 bytes to the beginning of each of your images so what we need is just a small