Alfred Posted May 2, 2020 Share Posted May 2, 2020 Is there anybody working on any 65816 projects ? Drac030 has released his ELSA, there's MAE and a couple of cross-assemblers like the WDC one. Just curious if there's anyone actually tinkering with anything to run on one of the 65816 upgrade boards. It occurred to me that with a custom runtime, it ought to be not too hard to get compiled Action! code to run above the 64K boundary. There'd be some restrictions of course on how some things would need to work, but it would give you a lot more memory to play with. 5 Quote Link to comment Share on other sites More sharing options...
tebe Posted May 2, 2020 Share Posted May 2, 2020 Drac030 wrote the ZX emulator for 65816 3 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 2, 2020 Share Posted May 2, 2020 And the CP/M 2.2 emulator using the same Z80 engine. But I understand that OP is asking about projects currently being in development. I am slowly writing a disassembler. The dissassembling part is sorta ready already (with some cosmetics to be applied), but the program currently does nothing else. I have recently got some inspiration, namely an Apple IIGS disassembler called "The Flaming Bird Disassembler", which is said to be the best one on that platform. So maybe eventually it will become something actually usable. I sorta feel that the thing we are lacking is something like Apple's IIGS system loader. I guess the sources are available, so maybe it is time to sit and port it. 6 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 3, 2020 Share Posted May 3, 2020 Whoa - what is this about a CP/M emulator? 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 3, 2020 Share Posted May 3, 2020 I mean this program http://drac030.krap.pl/en-cpm-info.php 4 Quote Link to comment Share on other sites More sharing options...
leech Posted May 8, 2020 Share Posted May 8, 2020 On 5/2/2020 at 5:21 PM, drac030 said: And the CP/M 2.2 emulator using the same Z80 engine. But I understand that OP is asking about projects currently being in development. I am slowly writing a disassembler. The dissassembling part is sorta ready already (with some cosmetics to be applied), but the program currently does nothing else. I have recently got some inspiration, namely an Apple IIGS disassembler called "The Flaming Bird Disassembler", which is said to be the best one on that platform. So maybe eventually it will become something actually usable. I sorta feel that the thing we are lacking is something like Apple's IIGS system loader. I guess the sources are available, so maybe it is time to sit and port it. On that note... what are your thoughts on making an Apple IIGS emulator? I have been thinking with the Rapidus it has a faster CPU, VBXE would give it better graphics capability, the only real thing missing would be sound... haven't figured that one out yet. Otherwise I'd think it would be possible and awesome to run GS/OS on an accelerated Atari 8bit. Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 8, 2020 Share Posted May 8, 2020 My main problem with Apple IIGS is that I know next to nothing about the architecture of that machine, or Apples II in general. They are not so popular in Europe, so it has been just few years since I saw an Apple IIGS, and it was also the only member of the Apple II family I ever have seen. The second question is whether it is required to fully emulate the machine including the CPU in software (the CPU may be half-emulated, in the way some debuggers work, i.e. basically set a BRK after an instruction and let the CPU execute it), or maybe it would be enough to natively port the GS/OS - and here I am not sure if this would make the Apple IIGS programs work, because I do not know how hardware-abstracted the average GS application is: I saw many programs (mainly games) using the windowed interface, but if a program draws a dialog box, it unfortunately does not prove that it is using the OS interface to do that. On ST I happened to see programs which drew GEM-like windows and boxes, and it looked credible as long as you did not replace the AES with a version with different gadgets and decorations, and the program in question still looked like it did under the original TOS. So the huge task of porting GS/OS may be going to be done in vain, as we will then have yet another OS without any software for it. Quote Link to comment Share on other sites More sharing options...
leech Posted May 8, 2020 Share Posted May 8, 2020 2 hours ago, drac030 said: My main problem with Apple IIGS is that I know next to nothing about the architecture of that machine, or Apples II in general. They are not so popular in Europe, so it has been just few years since I saw an Apple IIGS, and it was also the only member of the Apple II family I ever have seen. The second question is whether it is required to fully emulate the machine including the CPU in software (the CPU may be half-emulated, in the way some debuggers work, i.e. basically set a BRK after an instruction and let the CPU execute it), or maybe it would be enough to natively port the GS/OS - and here I am not sure if this would make the Apple IIGS programs work, because I do not know how hardware-abstracted the average GS application is: I saw many programs (mainly games) using the windowed interface, but if a program draws a dialog box, it unfortunately does not prove that it is using the OS interface to do that. On ST I happened to see programs which drew GEM-like windows and boxes, and it looked credible as long as you did not replace the AES with a version with different gadgets and decorations, and the program in question still looked like it did under the original TOS. So the huge task of porting GS/OS may be going to be done in vain, as we will then have yet another OS without any software for it. Yeah, I would think emulation would somehow be easier than porting the OS. As yku say, the CPU itself probably doesn't need to be emulated, as it is a 65816 running qt 2.8mhz. Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Author Share Posted May 11, 2020 On 5/2/2020 at 7:21 PM, drac030 said: I sorta feel that the thing we are lacking is something like Apple's IIGS system loader. I guess the sources are available, so maybe it is time to sit and port it. I went looking to see what it does. What is it you think we're missing that the Apple system loader provides ? The ability to load binaries above 64K or relocating code into the different banks ? Anyway, in between working on 65816 stuff, I decided to try my idea of relocating an Action! program to run above 64K. To that end I've just written a new runtime library that allows the runtime routines to access code in the lower bank. There are some problems with running above the line, as in reading memory in bank zero is not possible, so Action! statements like: BYTE dma=$022F will not work correctly. I've added some new functions like PeekL, and PokeCL that allow access to memory in other banks, as well as a new MoveBlockLong. It's not ideal, but without rewriting the compiler it's probably the best that can be done with what exists right now. I just have to adapt my 65816 binary loader from years ago to have it relocate the Action! binary and execute it. If anybody's interested I can post the final result when I have it all working. 2 Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Author Share Posted May 11, 2020 (edited) Man, we really need a tool to transcribe an assembler listing to the proper Action! format. This is stupid boring typing in these code blocks. Probably more boring than typing in the Action! manual. Edited May 11, 2020 by Alfred 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 11, 2020 Share Posted May 11, 2020 9 hours ago, Alfred said: The ability to load binaries above 64K or relocating code into the different banks ? The relocation mechanism, of course. It is not a big deal to write a loader like that (my ZX Spectrum emu internally uses a relocating loader, therefore its main part can be loaded anywhere above 64k), but the Apple thing is already there and it is, I supposed, debugged suficiently and tested in action, so why not to use it. As to the Action! stuff, maybe there should be two versions: 1 which runs entirely above the 64k, and 2 which has the code above 64k and uses bank 0 as the DBR. 2 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 11, 2020 Share Posted May 11, 2020 (edited) The mention of the Action runtime library made me think about some problem I have stumbled upon several times since I am using the Rapidus accelerator. Namely, the Pokey's RANDOM register $d20a is too slow. Normally one should wait 8 clock cycles between consecutive reads, and with a CPU clocked at 1.77 MHz it is not a problem, but on Rapidus the 8 slow bus cycles are equal to over 90 CPU cycles, so if one does a LDA RANDOM twice in a row, the results may be visibly correlated. I wrote a small test program. It opens a pixel mode, then generates a random color, x in range 0-255 and y in range 0-127, sets the pixel, then repeats the whole procedure of generating coordinates and colors again. I used the VBXE "stdres" pixel mode (320x192/256 colors). TESTRND.OBJ The result at 1.77 MHz: The result at 21 MHz (Altirra, on my Rapidus it is even worse): (The problem can be also observed in TBXL, GR.24:C.1:DO:PL.RAND(320),RAND(192):LOOP) Of course, one can always do STA WSYNC after every read, but this is wasting a lot of the CPU time, and besides, there are situations when you want/need to generate several random bytes in a row as fast as possible. So instead of STA WSYNC one could read $D20A eight (or seven) times in a row, which should guarantee that the value in the shift register gets completely shifted out between consecutive reads. Eight consecutive reads of RANDOM is, if I calculate correctly, over 200 CPU cycles at 20 MHz. This seems to cure the problem on accelerators, but I wonder if it cannot be done slightly faster without impairing the randomness in a visible way. 1) Have a variable in the memory, let us label it _fix 2) init it at the start of the program lda random / sta _fix 3) maybe init it similarly from time to time, possibly asynchronously from any main loop, i.e. on a VBL, on keyboard input etc. depending on the nature of the program 4) instead of lda random, do this: lda _fix asl adc #$00 asl adc #$00 sta _fix eor random cmp _fix bpl exit ldy random sty _fix exit ... This is ~47 clock cycles best case, and ~75 worst case, if I calculate correctly, assuming that the average I/O access on Rapidus takes 25 cycles of the fast CPU clocks. It is certainly better than 200 cycles. The program: TESTRND2.OBJ And the result: Edited May 11, 2020 by drac030 first post was a bit messed up 3 Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Author Share Posted May 11, 2020 6 hours ago, drac030 said: As to the Action! stuff, maybe there should be two versions: 1 which runs entirely above the 64k, and 2 which has the code above 64k and uses bank 0 as the DBR. Well the only way for Action! to run entirely within a bank would be to have a CIO that allows calls from outside bank zero, which doesn't exist today. PBR <> DBR is even more problematic, because internally Action! stores into the code, as part of FOR loops and as used in the PROC/FUNC assignment, ie: Error=MyError . So unless the compiler is changed to either not do that or perhaps generate a long absolute reference, DBR must always equal PBR for Action!. PL65 perhaps could be modified to run with DBR<>PBR because it seems to be entirely stack based. I don't have a complete disassembly of the PL65 compiler though. 1 Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 11, 2020 Share Posted May 11, 2020 8 minutes ago, Alfred said: Well the only way for Action! to run entirely within a bank would be to have a CIO that allows calls from outside bank zero, which doesn't exist today If it is about the calls alone, my OS allows to call the CIO (or any 6502 system function you want) from anywhere in the memory. Also without a special OS it is possible to setup a wrapper in the first 64k, like this: jsr ciov rtl then call it with JSL. 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Author Share Posted May 11, 2020 1 hour ago, drac030 said: If it is about the calls alone, my OS allows to call the CIO (or any 6502 system function you want) from anywhere in the memory. Also without a special OS it is possible to setup a wrapper in the first 64k, like this: jsr ciov rtl then call it with JSL. CIO only has 2 bytes for the buffer address at $0344/$0345. How does your CIO accept a 3 byte address from a call beyond bank 0 ? Quote Link to comment Share on other sites More sharing options...
drac030 Posted May 11, 2020 Share Posted May 11, 2020 It obviously does not (it is not possible, because it does not depend on the CIO only, but also all its drivers, DOS etc.), the calls are possible, though. Transferring the data another way than a byte per call obviously makes the matter harder, an intermediate buffer must be setup in bank 0 to move the stuff to and fro. Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 11, 2020 Author Share Posted May 11, 2020 (edited) Just now, drac030 said: It obviously does not (it is not possible, because it does not depend on the CIO only, but also all its drivers, DOS etc.), the calls are possible, though. Transferring the data another way than a byte per call obviously makes the matter harder, an intermediate buffer must be setup in bank 0 to move the stuff to and fro. Ok. I thought you meant you had a CIO that allowed for interbank calls. Yes, the DataQue OS has a similar feature, you can JSL NATVEC with the address of the OS routine you want to invoke in one of the registers, but you still have to deal with the issue of putting the data somewhere the stock OS can access it. Action! already uses page 5 for string operations, so I use it in my 816 runtime as a buffer area. Edited May 11, 2020 by Alfred Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 31, 2020 Author Share Posted May 31, 2020 How do you add text after you upload a picture ? The editor doesn't seem to allow you to do that, you can't put the cursor below the pic box. There must be a way though, because Drac030 did it earlier in this thread. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 31, 2020 Share Posted May 31, 2020 2 hours ago, Alfred said: There must be a way though, because Drac030 did it earlier in this thread. Add some EOLs to the message first, so you can drag the picture box up to open up some blank lines below it? Quote Link to comment Share on other sites More sharing options...
Alfred Posted June 1, 2020 Author Share Posted June 1, 2020 4 hours ago, flashjazzcat said: Add some EOLs to the message first, so you can drag the picture box up to open up some blank lines below it? Turns out it's the post to reply button on the thumbnail. Anyway, now that I have a working 65816 assembler I've started work on a couple of 65816 projects. First is a runtime library to allow Action! programs to be run in banks other than 0. The first version wasn't very good, so I'm redoing it. The other project is a native 65816 DOS. I actually started on this back in 2003 according to the source, although then it wasn't really a 65816 project. I decided then that while SpartaDos was great, hardware problems with the Black Box and other things meant corruption on the disk was rarely detected. So I devised a scheme not unlike DOS XE for sector links with maps like SpartaDos. The other objective was to support larger than 16MB partitions; the BB I believe can do 48MB. Puff thinks there's a reason why it can't do 64MB but he doesn't remember now what that reason is. A 6502 version will likely also get done because I really hate that my 1MB 800 is stuck with MyDOS. Yes, I know about SDX, but I never found the cartridges to be reliable and anyway I just prefer a disk-based DOS, so no point in lecturing me that I'm wasting my time. Eventually it will also handle SpartaDos and AtariDos formats. 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 1, 2020 Share Posted June 1, 2020 6 hours ago, Alfred said: Turns out it's the post to reply button on the thumbnail. Oh my. I assumed we were already beyond that point. Quote Link to comment Share on other sites More sharing options...
tebe Posted June 1, 2020 Share Posted June 1, 2020 DOS6.4 65816 fix, probably by Drac030 dos64_fix.atr Quote Link to comment Share on other sites More sharing options...
leech Posted June 1, 2020 Share Posted June 1, 2020 56 minutes ago, tebe said: DOS6.4 65816 fix, probably by Drac030 dos64_fix.atr 90.02 kB · 2 downloads Reminds me, I need to find a 65816 BASIC to put on the U1MB. Quote Link to comment Share on other sites More sharing options...
+David_P Posted June 2, 2020 Share Posted June 2, 2020 20 hours ago, leech said: Reminds me, I need to find a 65816 BASIC to put on the U1MB. MultiBASIC v.0.32 An Atari BASIC compatible interpreter for 65C816 Atari machines http://drac030.krap.pl/en-mb-pliki.php Note though that this doesn't fit in the normal 8K cartridge space. 1 Quote Link to comment Share on other sites More sharing options...
leech Posted June 2, 2020 Share Posted June 2, 2020 18 minutes ago, David_P said: MultiBASIC v.0.32 An Atari BASIC compatible interpreter for 65C816 Atari machines http://drac030.krap.pl/en-mb-pliki.php Note though that this doesn't fit in the normal 8K cartridge space. Has it been tested with loading through the U1MB? Figured I could put it in there, as currently whenever I try to use BASIC, it just gives me errors. Though I think the Altirra Emulator also has one that I could try. I really need to finish learning Assembly... Quote Link to comment Share on other sites More sharing options...
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.