![]() With bit-stream it'll take: 36 cycles (on average) (or ~11 opcodes) to read a nibble. loop 3 cycles (branch taken, no page cross)Ĭurrently it takes: 4+2 = 6 cycles (or 2 opcodes) to read a nibble The advantage of just dealing with the bitstream model is it's just a single format that AppleWin deals with, instead of having to support both nibble & bitstream.īPL. nib format (and further lost when converting. These would just be lost when converting back to. writing, AppleWin would now get a bitstream with extra zero-sync bits. reading, (I think) AppleWin wouldn't need to insert any extra (zero/sync) bits, as all nibbles are already in sync.Īnd when writing (or formatting) using an internal bitstream representation, but using a. nib image file to an internal bitstream representation: So the next step might be to "lower" (ie. nib images already exist in nibble track format). Currently all disk access is done at the nibble level (ie.dsk/po etc are converted to nibbles tracks and. Yes, I agree with that - we should strive not to lose any performance.Ī simple way forward would be to convert all disk access to a bitstream model. The existing disk code is, to use the made-up buzzword, performant, and it would be a shame to lose that. I wasn't really aware of these things (I've not read Sather's explanation in detail yet). Reading behaviour, so bit-stream changes are needed in the soft-switch code There's currently no convenient abstraction point in the code to switchĪs you can see with my points above, the soft-switch accesses change the The problem with keeping both byte and bit-stream disk access is that Though I suppose tools both in emulation and out could fill the gap for WOZ. That said, DO, PO and NIB images are very convenient to inspect and edit, Standard - closer to the behaviour of real hardware. Perhaps this is the best way, since I think WOZ images will become the new Time and then saved to WOZ images if necessary. One advantage would be that non-standard formatting can be written at any So when writing nibbles from DSK etc or NIB to the buffer we can just Model, which IIRC is what MAME and OE have done. The existing disk code is, to use the made-up buzzword, performant, and itĪ simple way forward would be to convert all disk access to a bitstream Some of the sequencer code is redundant - namely that to detect zeroes,Īnyway, the real question is how to shove bit-stream disk access into ![]() ![]() C08D resets the sequencer - used in the bit-slip (E7) protection ![]() and longer if 0's come along (this is howīit copy programs detect "sync bytes/nibbles") When the high bit is set then the sequencer loops while the latch holds Shift bits, and generate spurious ones if thereīut the real-time specifics get a bit tricky eg: Here are the new changes:ġ40 What Apple has done is move the patch they had put at $BA84 down to $B6B3 and added fourġ41 extra lines to that patch.Yes, there will be a few interesting cases to test.īTW, your program sums up the basic logic of the sequencer and transitionĭetection amplifier well. I am going to assume you already have the "early 1983" version,ġ20 either because you bought a //e or a disk drive this year, or you copied one from a friend,ġ21 or you made the patches from my July article. The letter binds developers to begin using the newġ18 If you like APPEND, or would like to like it, you might want to make these patches inġ19 your own system master. 1983:ġ11 Yet Another New Version of DOS 3.3 Bob Sander-Cederlofġ13 In the July issue of AAL I outlined the changes Apple made to DOS 3.3 early this year.ġ14 Today I received a new "Developer's System Master", with a cover letter claiming anotherġ15 correction to the APPEND routine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |