Jump to content

drac030

Members
  • Content Count

    2,578
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by drac030

  1. ... and be aware that one and the same opcode may be executed in different number of cycles depending on the internal CPU state. E.g. LDA abs,X is "normally" 4 cycles, but 5 when a page boundary gets crossed. In that latter case the spare cycle could not be detected, and so it could not be shortened. This would exclude quite a number of frequently used instructions in frequently used (i.e. indexed) addressing modes, and that in turn makes the whole thing yet less worthwhile.
  2. Yes, as stated previously. For example, ASL absolute needs 6 cycles: a) 1 to fetch opcode, b) 2 to fetch argument, c) 1 to fetch operand, d) 1 to do the shifting, e) 1 to write operand back. Out of that the stage "d" is the internal operation cycle. Assuming you are able to identify, which cycle is internal, cut the CPU off the bus for that time and switch the clock to 3.5 MHz, you at best make the instruction occupy 5.5 instead of 6 cycles, i.e. you are gaining 1/12, that is, about 8%. Another is RTS: a) 1 to fetch opcode, b) 2 dummy cycles, c) 2 cycles to pull address from the stack, d) 1 to increment it. Out of that stages "b" and "d" can be shortened so that instead of 6 cycles the instruction takes 4.5. The gain here is at most 3/12, i.e. 25%. CLC: a) 1 opcode fetch, b) 1 dummy. By clocking at 3.5 MHz you gain 1.5 instead of 2 cycles, i.e. 25%. JMP: a) 1 opcode fetch, b) 2 argument fetch. No dummy cycles. Gain: 0. LDA abs: a) 1 opcode fetch, b) 2 argument fetch, c) 1 operand fetch. No dummy cycles. Gain: 0. And so on. Yes, because (again, as stated) it has signals which allow the external circuitry to identify the spare access cycles and act accordingly. But with just doubling the clock the overall speedup will be hardly worth the effort.
  3. These are all memory-access cycles. In 6502 you have only one RW line and it always indicates either read or write cycle.
  4. Long time ago (like around 2007) there was a prototype 65C816 accelerator. It could be configured so that the memory was running at the stock clock and the CPU was accelerated to 10.64 MHz (stock clock x6) - so the only speed gain in that configuration was from the internal CPU operations being fast, whereas memory accesses were slow. In that configuration the average speed gain was around 25%, i.e. just about the same as if you disabled the Antic DMA on a stock computer. I hope this anwers the question how much would one gain by just doubling the CPU clock.
  5. On 6502 (unlike on e.g. 65C816) every CPU cycle = memory access cycle. So without accelerating the bus you would get nothing.
  6. Ok, so this means that one sector is transmitted at 100 kilobytes/s. But 128 bytes per sector * 26 sectors per track = 3328 data bytes per track. 288 rotations per minute = 4.8 rotations per second. 3328 * 4.8 = 15974.4 bytes per second = 15.6 kilobytes/s maximum, with ideal sector skew. If so, saying to the press that the disks work at 100 KB/s does not seem very fair.
  7. I have compared 1450XLD OS-es (there are two versions) with 800XL OS some years ago and I do not remember any difference like that. If I am not mistaken, 1450XLD drives are supposed to be PBI devices. Which mean that they have own ROMs activated by the OS as necessary (the same mechanism is used by Karin Maxi external floppy drive, or IDE+ HDD, or whatever else). The "necessary" time is e.g. OS initialization. The PBI ROMs get called one by one, so this would be the opportunity to check if the drive has finished initializations (and to wait, if it did not) and if there is a floppy inserted. At least, that is my guess. Surely I would like to know how these drives work, how fast they are ("100 KB/s" mentioned in the sources probably means 100 kilobits/s) etc.
  8. Oups, a too-quick update apparently. What about now? svbxe109b.arc
  9. Indeed, that function was busted. Try this: svbxe109.arc There is yet some bad interaction between this driver and the CON.SYS driver regarding the local color. The symptom is that after POKE $2F4,$81 (or $83) any new characters are not visible. I am currently not sure how to solve that, but there is a workaround: after POKE'ing as above, just do CLS or, if clearing the screen is not desirable, do POKE 711,PEEK(709) (i.e. copy the global foreground color to the local foreground color).
  10. It will work with anything provided that the disk's geometry is the same as in Indus CP/M, that is: 1 side, 40 tracks, 18 sectors per track, 128 or 256 bytes per sector, two first tracks reserved, block size 1k, directory size 1 block in SD and 2 blocks in DD. Also, in DD soft interleave 1:1 is assumed, and 1:5 in SD. It could be configurable, of course, but there was no demand
  11. Just out of curiosity: when I enable "Fast boot", what do I get over not having enabled it?
  12. I would guess that "DM" = Display Memory. It is calculated correctly regarding the RAMTOP. Just it is not regarding the Antic inability to cross a 4k boundary without the LMS. Thus if lowering RAMTOP for GR.8, one should always lower it by 4k (16 pages).
  13. I have uploaded version 0.94 to the same address as above. One major new thing is that ELSA is now able to generate SpartaDOS X relocatable binaries. I seem to have managed to make SpartaDOS X support more flexible than in MADS (let alone FA), for example, all 65C816 instructions and addressing modes will generate fixups, where applicable; also, labels declared as external symbols can be used in arithmetic expressions, the result of such an expression will then generate the external reference record when used, e.g. .xref COMTAB lbuf = COMTAB+$3f ... ... lda lbuf "lda lbuf" will cause the XREF record for the symbol "COMTAB" to be inserted into the object file. Also, fixups work between program blocks loaded to different 64k segments. To use this one will need to load an additional extension module, which will come with next beta release of SDX (on the Toolkit).
  14. It will not. Most SDX utilities and external commands (like all except one or two) are in the relocatable binary format which 3.2 does not understand, and require the SDX Library, which 3.2 does not contain.
  15. Yup, it has always been so in SDX: "path to root directory", when at the root, it is NUL.
  16. I know, I am just saying that it is no matter that the manual says "Dx:", because this does not forbid using "D:" anyways. Of course SD 3 (maybe except 3.2g) has no concept of current drive IIRC, so what is "current" must be established by other means.
  17. That is no matter: "Dx:" in SpartaDOS X also means "D:" (then x = current drive and is implied).
  18. It was said above that SpartaDOS should use the current drive. It might be worth then taking a look a the code which gets the information on the current drive from the system and how it is done.
  19. After the recent, much revealing discussion on the left margin issue in CC65 libs, I would not be much surprised if it was the latter. Yes, "\" and ">" are equivalent as path separators in SDX.
  20. To be honest, I do not know - my first SpartaDOS years back then was SpartaDOS X and so it remains until this day. The CIO is not often used in SDX utilities, so I just checked, if XIO 48 works as advertised in the SDX User's Manual, section 6.3.18. But it seems so: The program: test.zip
  21. It seems that the limit of TSR programs initialized at reset has been exceeded. It is pretty short I admit (5 or so), SDX drivers do not need it, but OS drivers (E: and such) do, you install four of them... Try installing TSR.SYS (it is to be found on the Toolkit disk) as one of the first programs after SPARTA.SYS/SIO.SYS/[clock].SYS, then see if it helps.
  22. I cannot see any problem with soft reset, everything seems to survive. Could you provide steps to reproduce? Your post #163 was excellent
  23. @drpeter about the TD bug, try this: tdfix.com and see if it is any better.
  24. Yup, User's Manual: But the second issue is real and I will have to take a look at it. There is definitely something depraved there (and it is related to TD _again_, I am seriously about to dislike this program).
×
×
  • Create New...