Jump to content
IGNORED

65816 Projects


Recommended Posts

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.

  • Like 5
Link to comment
Share on other sites

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.

 

obraz.thumb.png.1c3ec737eca5a8d54c070131efd82d34.png

 

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.

  • Like 6
Link to comment
Share on other sites

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.

 

obraz.thumb.png.1c3ec737eca5a8d54c070131efd82d34.png

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

 

 

 

  • Like 2
Link to comment
Share on other sites

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 by Alfred
  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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:

 

rnd_177_mhz.png.548025a3b7eea2a9a33ff0c6da198896.png

 

The result at 21 MHz (Altirra, on my Rapidus it is even worse):

 

rnd_21_mhz_a.png.b71d88936874dae07e0a157c1c032223.png

 

(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:

 

rnd_21_mhz_b.png.1c5667298e63c3af7e709dd07dcb5d45.png

 

 

 

 

 

Edited by drac030
first post was a bit messed up
  • Like 3
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

 

 

  • Like 1
Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Alfred
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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.

 

 

 

 

  • Like 3
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...