It is currently Mon Dec 10, 2018 8:01 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 26, 27, 28, 29, 30  Next
Author Message
PostPosted: Sat Jul 07, 2018 8:55 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2777
I think I attempted making one a long time ago, but I forgot where it is.


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 10:34 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3715
Location: Mountain View, CA
Oziphantom wrote:
How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator?

I expect by linking my collection of 65816-related assembler documentation that you will read it. When I said, quote, "top-grade assembler", I am not kidding. You'll understand soon enough. But I feel you're asking the wrong question. There is no point in trying to "port ORCA/M" in its entirety. The question you should be asking is "what ORCA/M directives does Toshi's lcc816 emit", followed by looking at it, followed by referencing the ORCA/M manual for answers, followed by changing the relevant code in lcc816 to emit output for other types of present-day assemblers. When Charles Doty said that he did a SNES homebrew in a heavily-modified lcc816, I'm fairly sure this is what he meant (combined with probably lots of macro/code generation changes and optimisation; Charles does 65816 just like the rest of us). So, really, spending the time to examine TM's lcc816 would probably make a better first step... if someone even wants to do it. Talk is cheap these days, and I'm just as subject to that statement as anyone else.


Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 11:31 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2777
I have a working signed and unsigned 16x16 to 32bit multiplication routine, for anybody working on a library.

Code:
signed_16_bit_multiplication:
stz {product}+2         //high word of product needs to be cleared
sep #$10
ldx {temp}
stx $4202
ldy {temp2}
sty $4203         //set up 1st multiply
   ldx {temp2}+1
   clc
lda $4216         //load $4216 for 1st multiply
stx $4203         //start 2nd multiply
   sta {product}
lda $4216         //read $4216 from 2nd multiply
ldx {temp}+1
stx $4202         //set up 3rd multiply
sty $4203         //y still contains temp2
   adc {product}+1
adc $4216         //add 3rd product
sta {product}+1
ldy {temp2}+1
sty $4203         //set up 4th multiply
   lda {product}+2      //carry bit to last byte of product
   bcc +
   adc #$00ff
+;
adc $4216         //add 4th product
cpx #$80         //x is currently temp high byte
bcc +
sbc {temp2}
+;
cpy #$80         //y is currently temp2 high byte
bcc +
sbc {temp}
+;
sta {product}+2         //final store
rep #$10
rts


unsigned_16_bit_multiplication:
stz {product}+2         //high word of product needs to be cleared
sep #$10
ldx {temp}
stx $4202
ldy {temp2}
sty $4203         //set up 1st multiply
   ldx {temp2}+1
   clc
lda $4216         //load $4216 for 1st multiply
stx $4203         //start 2nd multiply
   sta {product}
lda $4216         //read $4216 from 2nd multiply
ldx {temp}+1
stx $4202         //set up 3rd multiply
sty $4203         //y still contains temp2
   adc {product}+1
adc $4216         //add 3rd product
sta {product}+1
ldy {temp2}+1
sty $4203         //set up 4th multiply
   lda {product}+2      //carry bit to last byte of product
   bcc +
   adc #$00ff
+;
adc $4216         //add 4th product
sta {product}+2         //final store
rep #$10
rts



Top
 Profile  
 
PostPosted: Sat Jul 07, 2018 3:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
koitsu wrote:
If I could magically wave my arms and make something happen, it would be to fix/improve 65816 support for cc65 and ca65 (the assembler, which does not cater well to 65816 in its present form

I actually think 65816 support in CC65 would be a detriment; writing an alternate CRT library for it would be okay, but I think it would add so much complication to the internal code generators to support both 8 and 16 bit that it would be a huge drag on the project going forward.

A fork of CC65, on the other hand, that doesn't have a mandate to continue its primary support for the 8-bit 6502, might be fairly feasible for an interested programmer? Maybe you could even replace enough modules from the original completely, so that you have a separate compiler binary that can otherwise share some code cleanly with the original CC65...

CA65, on the other hand, has rather good support for 65816, in my view, and it was very practical for it to do so.


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 1:18 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
koitsu wrote:
Oziphantom wrote:
How modular is ORCA, it is probably fairly easy to get a 65816 simulator and then enough Apple //gs file system rom mocked enough to give it what it expects and then run the ORCA assembler at ghz speed on a pc without having to go through a whole //gs emulator?

I expect by linking my collection of 65816-related assembler documentation that you will read it. When I said, quote, "top-grade assembler", I am not kidding. You'll understand soon enough. But I feel you're asking the wrong question. There is no point in trying to "port ORCA/M" in its entirety. The question you should be asking is "what ORCA/M directives does Toshi's lcc816 emit", followed by looking at it, followed by referencing the ORCA/M manual for answers, followed by changing the relevant code in lcc816 to emit output for other types of present-day assemblers. When Charles Doty said that he did a SNES homebrew in a heavily-modified lcc816, I'm fairly sure this is what he meant (combined with probably lots of macro/code generation changes and optimisation; Charles does 65816 just like the rest of us). So, really, spending the time to examine TM's lcc816 would probably make a better first step... if someone even wants to do it. Talk is cheap these days, and I'm just as subject to that statement as anyone else.
Modular is probably not the right word, or at least doesn't easily convey what I meant.
The Docs are there and the assembler doesn't look that intense, I have assemblers on the C128 that are getting to be as much, not quite as much but getting there, no linker though. However the whole package is quite complete, the debugger for example. My question was more does it roll everything itself or does it have a small program set that one can fire form what ever Apple //gs uses. Its been a long time since I've used one. Is it a ProDos? set, or did it throw the Apple stuff out the window and roll its own. The Docs mention how to do everything in the shell, but does the assembler exist by it self and can just be run from prodos for example. Something that I feel can probably only be answered by somebody familiar with the tool and the Apple //gs.
I agree its not the best long term solution and one would only do what is needed. However if one could easily get the assembler and linker running in a simulator it would greatly add testing I would think as you can then write tests to check the binary comparability of the original output vs 'the new system'


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 5:24 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3715
Location: Mountain View, CA
ORCA/M only runs under GS/OS, and from a system with a hard disk (you heard me right). It includes a CLI shell and tons of tools -- meaning: an entire development environment. It isn't an assembler/tool suite that is intended to be used from, say, a bootable floppy disk running ProDOS 8. Merlin 8/16 is more for the latter. ORCA/M is a very large suite of programs -- Byteworks also made a Pascal compiler (ORCA/Pascal) and a C compiler (ORCA/C) for the IIGS too. The shell is just what makes using the programs necessary, because the IIGS (incl. in GS/OS) does not provide a native CLI. So, the ORCA shell is what makes using the tools possible.

But for Toshi's stuff, you don't need to run ORCA/M to port his work over to a different assembler. All you need is to understand the ORCA/M assembler's syntax -- Chapters 18 and 19 are important -- and then convert whatever code is generated into output for other assemblers that you want to use (ex. WLA-DX). You don't need a simulator, there's nothing to simulate***.

Anyway, it might not be necessary at all, instead different work can be done. I don't know how complete Toshi's work was at the time, but here's something I found:

There is apparently a different lcc816 port that can output 65816. It has IIGS support -- I can see it supports -target=wdc65816/iigs. That is to say: it has knowledge of different Apple IIGS capabilities, such as toolbox functions in GS/OS, ProDOS API/filesystem calls, GSBug interfacing, blah blah blah... but that's not important. What's important is the fact that it can generate 65816 from C, and its crt support seems OK. What's in the former directory are essentially the dags that control the code generation. The Apple IIGS itself doesn't have to be the "target platform", the SNES can be the target platform (and of course someone has to write all the necessary interfaces for MMIO registers blah blah if they want), but I'm not sure it's necessary at first (for just raw 65816 assembly generation); the multiplication/division routines for example, could be modified to use the SNES's mult/div MMIO registers/circuitry.

I believe that version of lcc816 could be modified to work for what people want. I can't exactly figure out what assembler it's outputting for -- Toshi's version from days of yore was outputting for ORCA/M, but this may be very different -- and the docs are a complete travesty (IMO), but a brief skim of some of the grammar and declarations (example) look like it it may be using some ORCA/M-like syntaxes but I imagine some other assemblers use similar syntax. Refer to ORCA/M's manual, Chapter 18 and Chapter 19 for some syntactical details.

Point is: all the necessary bits to get C->65816 generation are there. Someone just needs to build binaries for different platforms (ex. Win32, etc.) and try to figure it all out. I sound like a broken record, but: if people want it this bad, they will put in the effort to figure it out and make it work with what they want (ex. WLA-DX or whatever else). Changing those assembler syntactical details means you have to understand what the original syntax was intending to do. WLA-DX, for example, uses weird syntax (weird to me, anyway; I'm an old IIGS person :P), but it certainly has all the equivalents needed.

*** -- If you wanted to do that, for nostalgia reasons (or to get familiar with ORCA/M in general, you'd need an Apple IIGS emulator like KEGS, ActiveGS, etc. with a hard disk image and the ORCA/M floppy disks (there are 4, and it's commercial software -- yes I have them in .img format, as I bought the software long ago -- and you need a system that has multiple floppy drives (the installer has major bugs with disk identification if you've only got 1 drive)), install GS/OS (if not pre-installed on the HDD image), mount the ORCA/M installer disk, run the installer, swap in/out disks during the installation process, get ORCA/M installed, run the shell, and start playing with the tools. It's tedious for people who aren't old IIGS users (if you are, it'll feel like home); no IIGS emulator I know of (for the PC) supports a native way to get files to/from the "host" (PC) into the "guest" (IIGS / GS/OS). You have to use tools like CiderPress to manipulate Apple II disk images to put files from the PC into those, etc. and then mount them in GS/OS as disks. IIGS emulation does not have good native integration for the "host" (PC), so you're forced to do this. The IIGS is literally one of the most neglected emulated systems out there, IMO; even the Apple II/II+/IIE/IIC have better overall support emulation-wise.


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 8:21 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
I think the problem is
The people who want a C compiler for SNES, want it because they don't know 65816 and they don't know the SNES. So hooking up a C compiler from something else that then needs you to potentially modify images formats, make modifications to the output in ASM to make it work on the SNES due to its hardware quirks.
vs
Those who do have said skills, don't see the point in having a C compiler for a SNES and hence can't be bothered to put a lot of effort into to make one.

This needs a bunch of SNES devs who are thinking "man I could save so much time on a bunch of the code I write by having a C compiler handle the boring stuff like menus and intro/outro etc and modifying my existing code with small changes is getting to be too much of a drag." Who then band together using their SNES expertise to make a solution for themselves, that others can then use.
The main issue being there are not many of the 2nd option and none of the 3rd needed case.

( I think Apple II emulation is just bad in all senses, the //c+ for example isn't even emulated. The machine was not very popular despite all the propaganda Apple used to spew about it. It's a pity as the //gs is the best computer Apple have ever made. I wonder if there is a /// emulator ;) - beyond a novelty look I did a crazy thing )


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 10:35 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7802
Location: Seattle
Oziphantom wrote:
want it because they don't know 65816 and they don't know the SNES. So hooking up a C compiler from something else that then needs you to potentially modify images formats, make modifications to the output in ASM to make it work on the SNES due to its hardware quirks.
That set of requirements is not really any different from where the NES toolchain is right now...

From experience watching people come here using C on the NES, people don't seem to be too badly chagrined about having to look at the generated asm. They just want to program C first and foremost.

It's true that it'd be nice to have something like NESst; I don't know of an analog off the top of my head.

People don't need to write their own SPC700 drivers; they just need something similar to Famitone, that can play a soundtrack and sound effects.


Top
 Profile  
 
PostPosted: Sun Jul 08, 2018 2:48 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2777
calima wrote:
For me, the banking is the greatest PITA.

When did you have trouble with banking?


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 1:56 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 841
It's rather annoying compared to a flat address space of the Genesis, and having two banks (program and data) doubles the chance of bugs, as well as the manual handling. It's an awkward system that can be worked around, but having to in the first place is ugly.

On cc65 specifically, it doesn't support banking where you have to switch everything. On the NES, you can usually keep a fixed bank and switch another bank. If the compiler and runtime had 816 support in the "long only" sense - all subroutine jumps and returns were forced to jsl and rtl - it would help nicely, leaving only the data bank to manual handling, but even that is a decent amount of work.

That's part of why SNES work tends to take several times longer vs Genesis work.


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 6:37 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20851
Location: NE Indiana, USA (NTSC)
Something similar could be said about the segmented architecture of 8086, 80186, and 80286 compared to the flat memory model of i386, correct?


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 9:17 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
I don't think anybody would argue that a banking or overlapping memory space is better than a linear memory space for the programmer. Usually faster and easier for the machine in question thou ;) Although I have used overlays on linear memory space machines T_T

Although in practice I find the 65816's banking to be very generous and with a little planning mostly not an issue ;) Although one of my todo features it to make a CALL function, RETURN function construct that allows the the assembler to work out if I only ever call it from in bank or if it needs to be across bank, and set the JSR/L and RTS/L accordingly automatically for me. However this is below auto collapsing REP/SEPs on my list ;)


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 11:31 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 841
Yes, 286 is supposedly similar, but I'm too young to have experienced that.


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 11:40 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
calima wrote:
Yes, 286 is supposedly similar, but I'm too young to have experienced that.

C compilers had the "near" and "far" type modifier keywords for exactly this. (...and they were annoying. DPMI was such a relief for me when it happened.)


Top
 Profile  
 
PostPosted: Mon Jul 09, 2018 12:01 pm 
Online
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2347
Location: DIGDUG
Quote:
It's true that it'd be nice to have something like NESst [for the SNES]


It's on my TODO list to make one.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 26, 27, 28, 29, 30  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group