| |
Over the summer V: Oh god not another Rocky movie |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jeffrey Lee |
Message #80101, posted by Phlamethrower at 19:21, 12/9/2006, in reply to message #80079 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I think one of the ports-to-other-platforms listed that it had the Z80 emulation working. However the same day that I uploaded my code, I noticed that the PicoDrive website had died. And it still appears to be down now  http://www.finalburn.com/ seems to be back up again. 
*browses for a bit*
Hmm 
http://www.finalburn.com/fb/shots.html
So Burn'Out was just a dodgy port of an 80's arcade game made by Sega?
http://emustatus.rainemu.com/games/pdrift.htm
[Edited by Phlamethrower at 20:22, 12/9/2006] |
| |
 [ Log in to reply ] |
| |
|
JMB |
Message #80112, posted by jmb at 00:32, 13/9/2006, in reply to message #80097 |
Member
Posts: 467
|
<hypnotic suggestion>jmb really wants to fix 'as'</hypnotic suggestion> I do, do I?  I may take a look after I've hacked NS' pseudo selectors some more.
Our survey says: pass -objasm on the command line and it should work fine. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80113, posted by adrianl at 01:55, 13/9/2006, in reply to message #80100 |
Member
Posts: 1637
|
Well if that's all your using it for then it's easy to fix What else did you expect me to use it for? I'm hardly going to be calling the OSLib functions from assembler now, am I?
From assembler I just find it a handy way to have all the SWI numbers available in a modular fashion.
Anyway, after a little bit of tidying, but mostly modifying the build sequence so that it will - I hope - build with just the freely available gccsdk tools - here we are:
http://adrian.aemulor.com/downloads/picodrive.zip
I expect that to move onto the official site as soon as tlsa has finished his beautiful handiwork.
My next improvement will be to the screen rendering, so that it keeps a list of redraw rectangles and draws only within those rectangles  The plan is to make the DMA-based rendering into a small, self-contained library that will cope with the very different DMA hardware found on the Iyonix and A9home, so you'll see the source - particularly in video_out.c is a bit of a dog's breakfast currently. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80114, posted by adrianl at 02:00, 13/9/2006, in reply to message #80113 |
Member
Posts: 1637
|
Oh yeah, I started to make a single app dir that would automatically select the appropriate !RunImage, but the build system does not yet build !RunImage4 and 5 with the appropriate variables.... to build a RiscPC/A9home-compliant version (ie. no HWORD usage in the screen rendering) you'll need to modify cyclone.h.app and PicoDriveRISC.s.tile to undefine USE_HWORDS; strictly speaking only the latter change is required to get it working on the A9home but the performance difference is surely negligible, so there's a single build for those two platforms for now)
[Edited by adrianl at 03:00, 13/9/2006] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80117, posted by Phlamethrower at 08:14, 13/9/2006, in reply to message #80114 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
What have you done to the build process? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80118, posted by Phlamethrower at 08:23, 13/9/2006, in reply to message #80117 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It still doesn't like the oslib headers |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80135, posted by adrianl at 15:07, 13/9/2006, in reply to message #80118 |
Member
Posts: 1637
|
What have you done to the build process? Only changes that were necessary to make a working emulator, then changes (mostly reversing the above) to get it back to gcc/drlink/as only so that you could - I hope - build it.
Believe it or not, I didn't go changing anything just to wind you up. Anyway, quit griping, or I'll make it use RISC_OSLib!
It still doesn't like the oslib headers In what sense "doesn't like?" It certainly issues warnings (mostly about :CHR:0 and I know not why), but it no longer errors AFAIK. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80138, posted by Phlamethrower at 15:21, 13/9/2006, in reply to message #80135 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Believe it or not, I didn't go changing anything just to wind you up. But my beautiful makeall obeyfile! Gone! 
It still doesn't like the oslib headers In what sense "doesn't like?" It certainly issues warnings (mostly about :CHR:0 and I know not why), but it no longer errors AFAIK.
It got stuck when one of the OSLib headers tried to include Types.hdr (IIRC). I think you might have also left one of the makefiles using objasm, so that would explain why it didn't produce any errors for you |
| |
[ Log in to reply ] |
| |
|
Mag. Erhard F. |
Message #80143, posted by schwarzygesetzlos at 15:54, 13/9/2006, in reply to message #80138 |
Member
Posts: 5
|
Well, from the user perspective it just looks impressive in fullscreen! 
And from the Iyonix perspecitive there's a definitive need for a speed throttling to 100 Megadrive speed, especially because !Picodrive still seems getting faster. ;-) |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80145, posted by jmb at 16:09, 13/9/2006, in reply to message #80138 |
Member
Posts: 467
|
It got stuck when one of the OSLib headers tried to include Types.hdr (IIRC). I think you might have also left one of the makefiles using objasm, so that would explain why it didn't produce any errors for you It would appear that recent (i.e >= 6.60) versions of OSLib attempt to GET oslib/foo.hdr. ObjAsm appears to be able to cope with this (although only after passing it the _absolute_ path of the OSLib install; it doesn't appear to be capable of expanding path variables correctly :frown. AS, however, doesn't as, afaik, it doesn't attempt any filename mangling when running on RO. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80146, posted by adrianl at 16:23, 13/9/2006, in reply to message #80138 |
Member
Posts: 1637
|
But my beautiful makeall obeyfile! Gone! If it is, then it's only because I forgot to copy it into the zipfile! I haven't changed that AFAICR, but I've been using it.
It got stuck when one of the OSLib headers tried to include Types.hdr (IIRC). I think you might have also left one of the makefiles using objasm, so that would explain why it didn't produce any errors for you Quite possibly, but "that's easy to fix" |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80147, posted by adrianl at 16:25, 13/9/2006, in reply to message #80145 |
Member
Posts: 1637
|
It would appear that recent (i.e >= 6.60) versions of OSLib attempt to GET oslib/foo.hdr. ObjAsm appears to be able to cope with this (although only after passing it the _absolute_ path of the OSLib install; it doesn't appear to be capable of expanding path variables correctly :frown. I've always used GET OSLibSLib.Hdr.Foo - that's the habit I established (perhaps for a reason) and it avoids any ambiguity if you have a local hdr.PCI or hdr.Types file, for example.
AS, however, doesn't as, afaik, it doesn't attempt any filename mangling when running on RO. On RISC OS, I'd argue that the use of / as a directory separator in the GET filename is name-mangling! |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80148, posted by jmb at 16:38, 13/9/2006, in reply to message #80147 |
Member
Posts: 467
|
It would appear that recent (i.e >= 6.60) versions of OSLib attempt to GET oslib/foo.hdr. ObjAsm appears to be able to cope with this (although only after passing it the _absolute_ path of the OSLib install; it doesn't appear to be capable of expanding path variables correctly :frown. I've always used GET OSLibSLib.Hdr.Foo - that's the habit I established (perhaps for a reason) and it avoids any ambiguity if you have a local hdr.PCI or hdr.Types file, for example.
Indeed.
AS, however, doesn't as, afaik, it doesn't attempt any filename mangling when running on RO. On RISC OS, I'd argue that the use of / as a directory separator in the GET filename is name-mangling!
Sure, but the GET directive in the OSLib header files is as above. From looking at the code, I can't see that AS is touching the filename at all under RO. It could well be that something stupid is happening, however. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80149, posted by adrianl at 17:03, 13/9/2006, in reply to message #80148 |
Member
Posts: 1637
|
Ah, well, I still use an old version of OSLib. Maybe it has changed since then. |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80154, posted by jmb at 22:30, 13/9/2006, in reply to message #80148 |
Member
Posts: 467
|
Sure, but the GET directive in the OSLib header files is as above. From looking at the code, I can't see that AS is touching the filename at all under RO. It could well be that something stupid is happening, however. Well, not so much stupid as unhelpful. UnixLib has a feature which allows it to handle both RISC OS and Unix filenames. However, in some cases, it's ambiguous as to which form a path is in. Part of the disambiguation process is to try matching known suffixes and these can be configured by the user by setting the UnixEnv$progname$sfix variable appropriately. If this variable isn't set, then a bunch of default suffixes are used.
The Unix->RISC OS part of this code is also available when linking against GCCSDK's SCL stubs. Unfortunately, the appropriate environment variable was never being looked at by apps linked against libscl. AS is such a program.
Anyway, 3.4.6 r2 will have a fix for this issue, along with a bit of stupidity within AS fixed (it was previously incapable of matching hdr.foo, converting it to hdr/foo).
So yeah, PicoDrive now compiles with GCC/AS (with one small caveat: you'll need to hack the PicoDriveRISC MakeFile to invoke AS directly - GCC doesn't currently pass -I through to it, so it's not finding OSLib) |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80155, posted by adrianl at 23:28, 13/9/2006, in reply to message #80154 |
Member
Posts: 1637
|
So yeah, PicoDrive now compiles with GCC/AS Well I've probably just fixed that!
The latest archive builds !RunImage4 and !RunImage5 for the two different targets - 4=RiscPC&A9home (ARMv4), 5=Iyonix (ARMv5). Feel free to barf at that way it's done (and then fix the passing of -D through gcc to as so that it can be a wee bit tidier), and also to barf at the abuse of UtilityModule version number to decide which !RunImage to invoke  |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80172, posted by Phlamethrower at 19:00, 14/9/2006, in reply to message #80155 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So yeah, PicoDrive now compiles with GCC/AS Well I've probably just fixed that!
Nope
I'll try and get a working version uploaded tonight, after I've reinstalled GCCSDK. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #80176, posted by adrianl at 19:06, 14/9/2006, in reply to message #80172 |
Member
Posts: 1637
|
So yeah, PicoDrive now compiles with GCC/AS Well I've probably just fixed that!
Nope
I'll try and get a working version uploaded tonight, after I've reinstalled GCCSDK.
I was being facetious, as in I have fixed the fact that it worked!
Apparently this was not clear because jmb thought me a muppet too |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80178, posted by jmb at 19:11, 14/9/2006, in reply to message #80172 |
Member
Posts: 467
|
So yeah, PicoDrive now compiles with GCC/AS Well I've probably just fixed that!
Nope
I'll try and get a working version uploaded tonight, after I've reinstalled GCCSDK.
If it helps; the changes to Adrian's tree I needed were; hack MakeAll to build the right targets; add -IOSLib: to the ASM command in PicoDriveRISC/Makefile
Oh, also: http://moose.mine.nu/gcc (contains latest code, including a fix for the -I issue I mentioned before) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80184, posted by Phlamethrower at 19:28, 14/9/2006, in reply to message #80178 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
If it helps; the changes to Adrian's tree I needed were; hack MakeAll to build the right targets; add -IOSLib: to the ASM command in PicoDriveRISC/Makefile Yeah, I'd worked out the first bit, and would have worked out the second once I had a new copy of GCC.
Oh, also: http://moose.mine.nu/gcc (contains latest code, including a fix for the -I issue I mentioned before) Cheers You should really get an autobuilder setup for the GCCSDK |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80188, posted by Phlamethrower at 20:06, 14/9/2006, in reply to message #80178 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Your copy of GCC doesn't seem to work, jmb - it still won't find oslib/Types.Hdr |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80193, posted by jmb at 20:38, 14/9/2006, in reply to message #80188 |
Member
Posts: 467
|
Your copy of GCC doesn't seem to work, jmb - it still won't find oslib/Types.Hdr It's working fine for me. What does *show UnixEnv$as$sfix produce? |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80195, posted by jmb at 20:45, 14/9/2006, in reply to message #80184 |
Member
Posts: 467
|
Cheers You should really get an autobuilder setup for the GCCSDK
As it happens, 3.4.6r2 should be released at the weekend, anyway (unless John T discovers anything major It may well be an idea for the future; we used to provide nightly builds; I'm not sure what happened to that (although, with it taking so long to compile the behemoth even on decent hardware, it may not be such a good idea ) |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80196, posted by Phlamethrower at 20:49, 14/9/2006, in reply to message #80193 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Your copy of GCC doesn't seem to work, jmb - it still won't find oslib/Types.Hdr It's working fine for me. What does *show UnixEnv$as$sfix produce?
h:hdr:Hdr:S:s, which looks right to me. |
| |
[ Log in to reply ] |
| |
|
JMB |
Message #80198, posted by jmb at 20:59, 14/9/2006, in reply to message #80196 |
Member
Posts: 467
|
Your copy of GCC doesn't seem to work, jmb - it still won't find oslib/Types.Hdr It's working fine for me. What does *show UnixEnv$as$sfix produce?
h:hdr:Hdr:S:s, which looks right to me.
I assume that OSLib$Path is set? |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #80199, posted by Phlamethrower at 21:03, 14/9/2006, in reply to message #80198 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Bah! I missed the colon off of -IOSLib: |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #80294, posted by tlsa at 19:51, 15/9/2006, in reply to message #79879 |
Posts: 1097
|
http://picodrive.atspace.com/ and
http://notaz.atspace.com/index.html Adrian's pointed out that these sites don't have source.
Well, all we need to do is provide appropriate pokeage to the authors.
Have you e-mailed them? |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #80295, posted by tlsa at 19:59, 15/9/2006, in reply to message #80113 |
Posts: 1097
|
http://adrian.aemulor.com/downloads/picodrive.zip
I expect that to move onto the official site as soon as tlsa has finished his beautiful handiwork. http://picodrive.acornarcade.com/test.html
Screenshots, Compatibility and Mega Drive section not done yet. Enough done to launch anyway. The download links don't actually point to anything yet either. Once the downloads are sorted out, I'll move the front page to http://picodrive.acornarcade.com/
[Edited by tlsa at 20:59, 15/9/2006] |
| |
[ Log in to reply ] |
| |
|
Phil Mellor |
Message #80296, posted by monkeyson2 at 20:03, 15/9/2006, in reply to message #80295 |
 Please don't let them make me be a monkey butler
Posts: 12380
|
Pretty |
| |
[ Log in to reply ] |
| |
|
Michael Drake |
Message #80297, posted by tlsa at 20:30, 15/9/2006, in reply to message #79971 |
Posts: 1097
|
I found a NetSurf text area bug when making this post.
* Reply and quote to it
* Scroll right
* Try and drop a text file (e.g. a URL bar URL from NS) in amongst the quoted text.
The text placement doesn't seem to take into account the h-scroll position.
Also, in an empty text area, when you make a really long line of text for the first line (no spaces) an h-scrollbar is made. Then press return or type more lines of normal flowing (with spaces) text until you reach the bottom, it doesn't scroll down and make a v-scrollbar when your text starts to go under the h-scrollbar.
It only gives you a v-scrollbar when your text exceeds the total text area height (including the internal scrollbar), but it should happen when the text exceeds textarea height - scrollbar height.
[Edited by tlsa at 21:35, 15/9/2006] |
| |
[ Log in to reply ] |
| |
| Pages (10): |< <
8
> >|
|
