Re: TMS-09xx/1xxx thread (was New Dumps)
hydef
10/17/19 09:29 PM
I honestly don't know about it but if you think it's alright that's good )
I'm starting to add some case artwork views as requested.. I'm only going to add the top of the cases with the logos on. So far there's Donkey Kong, Oil Panic and Mickey & Donald
3,421
2,104,981
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Steve Bourg
10/17/19 08:13 PM
Yes, these are the droids I am looking for. You could try passing ARCHOPTS=-march=native to make (need to do REGENIE=1 for the change to take effect). Make sure the flag actually does anything by running $ gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 Don't hold your breath, but if a couple percent speed bump is all you need this might just do the trick. In the majority of my tests, mame binaries compiled on this odroid-n2 with ARCHOPTS=-march=native win by a sliver. It's such a tiny margin (typically 0.1% - .25%), and there are cases where the reverse is true. I couldn't fault someone for suspecting statistical noise. Same outcome whether compiled with gcc7 or gcc8. Worth a shot.
# gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
/usr/lib/gcc/aarch64-linux-gnu/8/cc1 -E -quiet -v -imultiarch aarch64-linux-gnu - -mlittle-endian -mabi=lp64 -march=armv8-a+crypto+crc -fstack-protector-strong -Wformat -Wformat-security
# gcc -E -v - </dev/null 2>&1 | grep cc1
/usr/lib/gcc/aarch64-linux-gnu/8/cc1 -E -quiet -v -imultiarch aarch64-linux-gnu - -mlittle-endian -mabi=lp64 -fstack-protector-strong -Wformat -Wformat-security
I'll also note here that I have best testing mame's maciici emulation performance, compiled with gcc7 vs. gcc8, and gcc7 is winning by a margin of nearly 2%. No net improvement for me, as I have been using gcc7 from the start.
55
962
Read More
|
|
Re: TMS-09xx/1xxx thread (was New Dumps)
hap
10/17/19 07:46 PM
Actually, the only necessary change was to extend the white rectangle background beyond the SVG border.
Those other settings are just so it's easier to see the border and the white rectangle in an editor (inkscape in my case), they don't change how the SVG is rendered.
3,421
2,104,981
Read More
|
|
Re: TMS-09xx/1xxx thread (was New Dumps)
hal3000
10/17/19 07:06 PM
Hi hap, Nice fix with the svg:s! I try to understand the change so that new ones are done correctly. Can you please confirm if the below changes are what's required for the fix? inkscape:pagecheckerboard="true"
borderlayer="true"
inkscape:showpageshadow="false" Cheers!
3,421
2,104,981
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
belegdol
10/17/19 06:26 PM
I may have just encountered a problem with crashoverride's bgfx changes (whether it's something specific to crashoverride's code that enables the use of bgfx or it's some other problem with bgfx on odroid-n2, or just something else about that compiled binary, I don't know). The game I'm playing consistently locks up at a screen change that only happens with that bgfx binary. So I recommend handling that contribution separately. I stopped using the patch you originally provided that completely disabled/stripped bgfx, and I have been using your second approach "BGFX to OpenGL ES if NO_X11". I believe it took both your "NO_OPENGL" and your "BGFX to OpenGL ES if no NO_X11" patches to get mame compiled on the odroid n2 without X. I would just mention that even with the second approach, running mame with "-video bgfx" did not work - I encounter the error:
../../../../../3rdparty/bgfx/src/glcontext_egl.cpp (177): BGFX 0x00000002: Failed to create display 0x0
Aborted
Your second approach did enable me to get MAME compiled/linked, and MAME's performance with -video accel is just 2% less than -video bgfx from crashoverride's patch. This runs at ~ 90% emulation speed on the odroid n2. So your second approach is a big win even without a working -video bgfx option. We have a bit of a problem. With the new bgfx simply switching to OpenGL ES no longer works, mame will fail to link: /usr/bin/ld: ../../../../linux_gcc/bin/x64/Release/libbgfx.a(glcontext_egl.o): in function `bgfx::gl::GlContext::createSwapChain(void*)':
glcontext_egl.cpp:(.text+0x82e): undefined reference to `eglGetCurrentSurface'
/usr/bin/ld: ../../../../linux_gcc/bin/x64/Release/libbgfx.a(glcontext_egl.o): in function `bgfx::gl::GlContext::destroySwapChain(bgfx::gl::SwapChainGL*)':
glcontext_egl.cpp:(.text+0x944): undefined reference to `eglGetCurrentSurface'
/usr/bin/ld: glcontext_egl.cpp:(.text+0x94c): undefined reference to `eglGetCurrentContext'
collect2: error: ld returned 1 exit status Adding -lEGL to LDFLAGS takes care of that - mame links and runs: diff --git a/scripts/src/3rdparty.lua b/scripts/src/3rdparty.lua
index 970afc7d45..2f108c7cd7 100644
--- a/scripts/src/3rdparty.lua
+++ b/scripts/src/3rdparty.lua
@@ -1383,6 +1383,14 @@ end
"__STDC_CONSTANT_MACROS",
"BGFX_CONFIG_MAX_FRAME_BUFFERS=128",
}
+
+ if _OPTIONS["NO_X11"]=="1" then
+ defines {
+ "BGFX_CONFIG_RENDERER_OPENGLES=1",
+ "BGFX_CONFIG_RENDERER_OPENGL=0",
+ }
+ end
+
files {
MAME_DIR .. "3rdparty/bgfx/src/bgfx.cpp",
MAME_DIR .. "3rdparty/bgfx/src/debug_renderdoc.cpp",
diff --git a/scripts/src/osd/sdl.lua b/scripts/src/osd/sdl.lua
index ed660e65f9..9cd5415c88 100644
--- a/scripts/src/osd/sdl.lua
+++ b/scripts/src/osd/sdl.lua
@@ -29,6 +29,10 @@ function maintargetosdoptions(_target,_subtarget)
"X11",
"Xinerama",
}
+ else
+ links {
+ "EGL",
+ }
end
if _OPTIONS["NO_USE_XINPUT"]~="1" thenThe issue is that putting forcing -lEGL whenever NO_X11 is specified is likely going to break windows and mac build at least. I feel like I am in over my head and that someone more familiar with interdependencies between X11, OpenGL and OpenGL ES should take care of incorporating the build switches.
55
962
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Tafoid
10/17/19 05:26 PM
That that stings, as I need a capability/fix as of 0201.. I'll definitely give it a try though. As it turns out, the maciici emulation doesn't suffer much of a performance hit from the memory system rewrite in 0.200. The actual point where the hit occurs is between 0.203 and 0.204, but I don't yet know which commit caused it. You could try compiling 0.203 and see if that gives you a performance boost. In some quick testing it appears refactoring/improving of m68kmmu on 11/2/18 and 11/3/18 (the machine broke down on initial commits and was fixed in 11/3/18) results in about ~10% drop in performance. Not sure if it can be undone or what the improvements are.
55
962
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
belegdol
10/17/19 04:45 PM
belegdol: can you run a build with VERBOSE=1 and post what flags are being used? Is this the output you're looking for?
3rdparty/genie/bin/linux/genie --distro=generic --OPTIMIZE=3 --NOWERROR='1' --target='mame' --subtarget='mame' --build-dir='build' --NO_OPENGL='1' --NO_X11='1' --NO_USE_XINPUT='1' --SOURCES='src/mame/drivers/mac.cpp' --NOASM='1' --osd='sdl' --targetos='linux' --PLATFORM='arm64' --gcc=linux-gcc --gcc_version=7 gmake
..
Precompiling src/emu/emu.h...
g++ -MMD -MP -MP -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DPUGIXML_HEADER_ONLY -DMAME_NOASM -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DPTR64=1 -I"../../../../../src/osd" -I"../../../../../src/emu" -I"../../../../../src/lib/util" -pipe -O3 -fno-strict-aliasing -Wno-unknown-pragmas -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion -Wno-error=deprecated-declarations -Wno-unused-result -Wno-array-bounds -Wno-cast-align -x c++ -std=c++14 -Woverloaded-virtual -Wsuggest-override -flifetime-dse=1 -x c++-header -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DPUGIXML_HEADER_ONLY -DMAME_NOASM -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DPTR64=1 -I"../../../../../src/osd" -I"../../../../../src/emu" -I"../../../../../src/lib/util" -o "obj/Release/emu.h.gch" -c "../../../../../src/emu/emu.h"
Yes, these are the droids I am looking for. You could try passing ARCHOPTS=-march=native to make (need to do REGENIE=1 for the change to take effect). Make sure the flag actually does anything by running $ gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 Don't hold your breath, but if a couple percent speed bump is all you need this might just do the trick.
55
962
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Robert Hildinger
10/17/19 04:29 PM
That that stings, as I need a capability/fix as of 0201.. I'll definitely give it a try though. As it turns out, the maciici emulation doesn't suffer much of a performance hit from the memory system rewrite in 0.200. The actual point where the hit occurs is between 0.203 and 0.204, but I don't yet know which commit caused it. You could try compiling 0.203 and see if that gives you a performance boost.
55
962
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Steve Bourg
10/17/19 02:37 PM
belegdol: can you run a build with VERBOSE=1 and post what flags are being used? Is this the output you're looking for?
3rdparty/genie/bin/linux/genie --distro=generic --OPTIMIZE=3 --NOWERROR='1' --target='mame' --subtarget='mame' --build-dir='build' --NO_OPENGL='1' --NO_X11='1' --NO_USE_XINPUT='1' --SOURCES='src/mame/drivers/mac.cpp' --NOASM='1' --osd='sdl' --targetos='linux' --PLATFORM='arm64' --gcc=linux-gcc --gcc_version=7 gmake
..
Precompiling src/emu/emu.h...
g++ -MMD -MP -MP -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DPUGIXML_HEADER_ONLY -DMAME_NOASM -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DPTR64=1 -I"../../../../../src/osd" -I"../../../../../src/emu" -I"../../../../../src/lib/util" -pipe -O3 -fno-strict-aliasing -Wno-unknown-pragmas -Wall -Wcast-align -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion -Wno-error=deprecated-declarations -Wno-unused-result -Wno-array-bounds -Wno-cast-align -x c++ -std=c++14 -Woverloaded-virtual -Wsuggest-override -flifetime-dse=1 -x c++-header -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DPUGIXML_HEADER_ONLY -DMAME_NOASM -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2 -DPTR64=1 -I"../../../../../src/osd" -I"../../../../../src/emu" -I"../../../../../src/lib/util" -o "obj/Release/emu.h.gch" -c "../../../../../src/emu/emu.h"
55
962
Read More
|
|
Re: TMS-09xx/1xxx thread (was New Dumps)
hap
10/17/19 02:09 PM
that step means darken by 15%
And with subtract, i mean subtract the color channels in the picture, for example you have hex color FFEEDD, you subtract 112233, you get EECCAA. Then when you add the 2 layers together in MAME with additive blending, you get the correct color.
3,421
2,104,981
Read More
|
|
Re: TMS-09xx/1xxx thread (was New Dumps)
hydef
10/17/19 02:03 PM
Hi hap,
Thanks for the method there. I'll try it but I'm bad with even basic maths so I'm not sure exactly what part of it means (subtract B from A and multiply B by (216/255)), but you seem to know exactly what you're talking about and that's why I failed it, because it needs a mathematical method instead of playing and guessing.
Yes. I realize they're very cropped and that's because they're the same dimensions as before I started to add the 4:3 crop bounds, didn't change them. Sucks a little but I figured they're basically widescreen games and this is my widescreen, full screen view
3,421
2,104,981
Read More
|
|
Re: TMS-09xx/1xxx thread (was New Dumps)
hap
10/17/19 09:32 AM
@hydef re: ssparky
Personally I don't mind the colors, they look ok to me. What bothered me more is that the LCD shadowing doesn't look nice on this game, makes it seem I'm seeing double.
Anyway, if you really want to improve the colors, I think there is a way:
- create 1 overlay with the colors you want for the 'background' ("A")
- create 1 overlay for the lcd segments ("B"), multiply B by (216/255)
- in an image editor, subtract B from A, save as C
- in MAME, add screen element, add C with multiply blend, add B with additive blend
Regarding the lines at edges of the screen for eg. dkjr. I see the cause. It's nanosvg anti-aliasing the white rectangle element against a black background. It's basically a small mistake in the SVG, I can fix it. But it means all lcd game .svg files need changing.
3,421
2,104,981
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Steve Bourg
10/17/19 07:17 AM
I may have just encountered a problem with crashoverride's bgfx changes (whether it's something specific to crashoverride's code that enables the use of bgfx or it's some other problem with bgfx on odroid-n2, or just something else about that compiled binary, I don't know). The game I'm playing consistently locks up at a screen change that only happens with that bgfx binary. So I recommend handling that contribution separately. I stopped using the patch you originally provided that completely disabled/stripped bgfx, and I have been using your second approach "BGFX to OpenGL ES if NO_X11". I believe it took both your "NO_OPENGL" and your "BGFX to OpenGL ES if no NO_X11" patches to get mame compiled on the odroid n2 without X. I would just mention that even with the second approach, running mame with "-video bgfx" did not work - I encounter the error:
../../../../../3rdparty/bgfx/src/glcontext_egl.cpp (177): BGFX 0x00000002: Failed to create display 0x0
Aborted
Your second approach did enable me to get MAME compiled/linked, and MAME's performance with -video accel is just 2% less than -video bgfx from crashoverride's patch. This runs at ~ 90% emulation speed on the odroid n2. So your second approach is a big win even without a working -video bgfx option.
55
962
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
belegdol
10/17/19 06:08 AM
The patch disabling bgfx entirely was not endorsed by upstream. We are thus left with 3 changes: - Switching BGFX to OpenGL ES if NO_X11 is specified - Allowing passing NO_OPENGL explicitly - bgfx changes by crashoverride The way to get those in would be via a pull request. I can make a PR with the two buildsystem changes later this week. The bgfx changes should ideally be submitted to bgfx upstream first ( https://github.com/bkaradzic/bgfx).
55
962
Read More
|
|
Re: c64 super sketch
Golden Child
10/17/19 12:54 AM
So once we have these equations, we can make a spreadsheet, and with a bit of trial and error, deduce what the original values of the paddles when it was calibrated. The values in VWCALDA8.VER are 58,20,193,115,84,20,70,70. ![[Linked Image from i.imgur.com]](https://i.imgur.com/DUb9zBP.png) We find that PDL0 was A=250 and B=655, and PDL1 was A=482 and B=885. ![[Linked Image from i.imgur.com]](https://i.imgur.com/807vXVB.png) the formulas in the sheet: ![[Linked Image from i.imgur.com]](https://i.imgur.com/vOS9qM7.png) ![[Linked Image from i.imgur.com]](https://i.imgur.com/o7Qh6Mb.png) From a cool article on the versawriter, I now know the length of the arms: 6 inches each and the dimensions of the main board: it measures 12" vertically and 13.5" horizontally. ATARI CLASSICS Volume 2, Issue 3 / June 1993 / PAGE 26 LOOKiNG BACK: WHAT IS VERSAWRITER? GARY MATTESON AC STAFF REVIEWER https://www.atarimagazines.com/atariclassics/v2n3/looking_back.php
28
1,354
Read More
|
|
Re: MAME on ODROID-N2 (Linux)
Steve Bourg
10/16/19 11:42 PM
I might have found a solution less drastic than ripping out bgfx entirely: due to logic in 3rdparty/bgfx/config.h and 3rdparty/bgfx/renderer_gl.h, bgfx appears to default to glx under linux. I have now tested the following hack: diff --git a/scripts/src/3rdparty.lua b/scripts/src/3rdparty.lua
index 4ec2084d0f..ea6fa2f506 100644
--- a/scripts/src/3rdparty.lua
+++ b/scripts/src/3rdparty.lua
@@ -1347,6 +1347,12 @@ end
"__STDC_CONSTANT_MACROS",
"BGFX_CONFIG_MAX_FRAME_BUFFERS=128",
}
+ if _OPTIONS["NO_X11"]=="1" then
+ defines {
+ "BGFX_CONFIG_RENDERER_OPENGLES=1",
+ "BGFX_CONFIG_RENDERER_OPENGL=0",
+ }
+ endWith this change, mame can be built with $ make NO_X11=1 NOWERROR=1 NO_USE_XINPUT=1 NO_OPENGL=1 without hitting linking errors with bgfx. Bgfx uses OpenGL ES afterwards too which might be helpful as well.
26a27
> # NO_OPENGL = 0
713a715,718
> endif
>
> ifdef NO_OPENGL
> PARAMS += --NO_OPENGL='$(NO_OPENGL)'
Hi Belegdol - Belmont's pixel format change allowed mame to run at console framebuffer, which is now in mame. The changes you provide above allowed me to compile mame without X / OpenGL on the odroid-n2. Is there any path forward to get this pulled into the mame? As well, there's another patch provided by crashoverride in this thread that enabled framebuffered bgfx from console. Any chance of getting this into mame?
55
962
Read More
|
|
MAME 0.214 crashes at startup on Catalina
Carbon
10/16/19 10:08 PM
Here's the output: dyld: Symbol not found: __ZTINSt3__112bad_weak_ptrE
Referenced from: /Applications/Emulation/MAME/./MAME
Expected in: /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
in /Applications/Emulation/MAME/./MAME
zsh: abort ./MAME
I built it using a beta of Xcode 11 before Catalina was released. Could that be the source of the crash?
0
11
Read More
|
|
Re: c64 super sketch
Golden Child
10/16/19 07:35 PM
So let's figure out how do get an Atari 800 screendump so we can really study VWCALSFT.BAS. There doesn't seem to be a printer for the Atari 800 driver, so we'll just do LIST and then pause the listing by toggling CTRL+1. A little lua script for screendump:
function ram(adr) return emu.item(manager:machine().devices[":ram"].items["0/m_pointer"]):read(adr) end
function between(c,a,b) return a<=c and c<=b end
function boffset(x,y) return y*40+x end
function scrascii(c) c=c&0x7f
if between(c,0,0x3f) then return c+0x20 end
if c==0x7f then return 32 end
if between(c,0x60,0x7f) then return c end
if between (c,0x40,0x5f) then return string.byte("*") end
end
function scrdump(startcol) startcol = startcol or 2 for y=0,23 do for x=startcol,39 do io.write (string.char(scrascii(ram(boffset(x,y)+ram(88)+ram(89)*256)))) end print () end end
-- a little test of our screendump
emu.keypost([[100 PRINT CHR$(125):FOR I=0 TO 5:PRINT:NEXT I:FOR I=0 TO 255:POKE I+PEEK(88)+PEEK(89)*256,I:NEXT I
RUN
]])
scrdump(0)
With a little bit of stitching we get a nice listing, though CHR$(125) doesn't come through so that was added manually. READY
LOAD "D:VWCALSFT.BAS
READY
LIST
100 GRAPHICS 8:POKE 752,1
110 DIM P8(8),P7(8),FS$(16),IO$(1)
120 N127=127:N947=947
130 LGTHL=8:LGTHH=0:AUX2=0
140 FS$="D:VWPDIV03.VER":AUX1=4:PTGT=7:GOSUB 30500
200 POKE 54018,56:POKE 54016,48:POKE 54018,60
430 POKE 20245,N0:POKE 20254,N0:POKE 20262,N0:POKE 20268,N0:POKE 20303,N0:POKE 20312,N0
440 POKE 20320,N0:POKE 20326,N0
2000 BS=1:POKE 764,255
2100 PRINT CHR$(125);
2105 IF BS>=5 THEN 3000
2110 PRINT "POSITION ARMS AS SHOWN IN DIAGRAM ";BS
2120 PRINT "PADDLE(0)= PADDLE(1)= "
2125 PRINT :PRINT "PRESS SPACE BAR WHEN READY";
2130 BS=BS+1
2140 GRAPHICS 8+32:POKE 752,1:SETCOLOR 2,0,0
2150 GOSUB 6000
2160 P8(BS-2)=P0:P8(BS+2)=P1
2170 GRAPHICS 7+32:POKE 752,1:SETCOLOR 2,0,0
2180 GOSUB 6000
2190 P7(BS-2)=P0:P7(BS+2)=P1
2200 POKE 656,1:POKE 657,12:PRINT P0;" ";:POKE 657,31:PRINT P1;" ";
2210 IF PEEK(764)=255 THEN 2140
2220 POKE 764,255
2300 PRINT CHR$(125):FOR WT=1 TO 130:NEXT WT:GOTO 2100
3000 PRINT CHR$(125);"CALIBRATION IS COMPLETE ":TRAP 5500
3010 A=P8(0):B=P8(1):FLG=0:GOSUB 5000
3020 POKE 1536,SL:POKE 1537,SH:POKE 1538,OL:POKE 1539,OH
3030 A=P8(6):B=P8(7):FLG=1:GOSUB 5000
3050 POKE 1540,SL:POKE 1541,SH:POKE 1542,OL:POKE 1543,OH
3060 FS$="D:VWCALDA8.VER":ADDL=0:ADDH=6:AUX1=8:PTGT=11:GOSUB 30500
3100 A=P7(0):B=P7(1):FLG=0:GOSUB 5000
3120 POKE 1536,SL:POKE 1537,SH:POKE 1538,OL:POKE 1539,OH
3130 A=P7(6):B=P7(7):FLG=1:GOSUB 5000
3150 POKE 1540,SL:POKE 1541,SH:POKE 1542,OL:POKE 1543,OH
3160 FS$="D:VWCALDA7.VER":ADDL=0:ADDH=6:AUX1=8:PTGT=11:GOSUB 30500
3600 TRAP 40000:RUN "D:VW"
3610 END
5000 IF A>=B THEN POP :GOTO 5500
5050 S0=8192/(B-A)
5060 IF FLG=1 THEN O0=S0*B:GOTO 5100
5070 O0=16384+S0*B
5100 SH=INT(S0)
5110 SL=INT((S0-SH)*256+0.5)
5120 OV=INT(O0+0.5)
5130 OH=INT(OV/256)
5140 OL=OV-OH*256
5200 RETURN
5500 GRAPHICS 0:PRINT "ERROR IN ARM PLACEMENT----"
5510 PRINT "PLEASE REVIEW THE INSTRUCTIONS AND"
5520 PRINT "THEN REBOOT THE DISK TO TRY AGAIN."
5530 PRINT :END
6000 W=USR(20224)
6010 P0=PEEK(20478)+256*PEEK(20479)
6020 W=USR(20228)
6030 P1=PEEK(20478)+256*PEEK(20479)
6040 RETURN
30500 FOR X=1 TO LEN(FS$):POKE 1599+X,ASC(FS$(X,X)):NEXT X
30600 POKE 1616,AUX1:POKE 1617,AUX2:POKE 1618,PTGT
30605 POKE 1408,ADDL:POKE 1409,ADDH:POKE 1410,LGTHL:POKE 1411,LGTHH
30610 M=USR(1624):IF PEEK(N947)>N127 THEN 30900
30630 M=USR(1627):IF PEEK(N947)>N127 THEN 30900
30635 M=USR(1630):IF PEEK(N947)>N127 THEN 30900
30640 M=USR(1633):IF PEEK(N947)>N127 THEN 30900
30650 RETURN
30900 TEMP=PEEK(N947):M=USR(1633)
30910 GRAPHICS 0:PRINT "I/O ERROR # ";TEMP:POP
30920 IF TEMP<>167 THEN 30960
30930 PRINT "HAVE YOU LOCKED 'VWCALDA8.VER' AND "
30940 PRINT "'VWCALDA7.VER?"
30950 PRINT "PLEASE UNLOCK AND REBOOT THE DISK":END
30960 PRINT "REBOOT THE DISK WHEN THE PROBLEM"
30970 PRINT "IS RESOLVED."
30980 END
READY
We read the paddles under two different graphics modes, graphic mode 8 and graphic mode 7. The 32 is added to not clear the screen (probably to speeds up the switching). Coming in BS starts at 2, and gets incremented on each pass. The BS-2 and BS+2 indexes put paddle0 values in indexes 0 to 3, and paddle1 values in indexes 4 to 7. Diagram 1 : P8(0)=paddle0 P8(4)=paddle1 Diagram 2 : P8(1)=paddle0 P8(5)=paddle1 Diagram 3 : P8(2)=paddle0 P8(6)=paddle1 Diagram 4 : P8(3)=paddle0 P8(7)=paddle1 The P8 array is filled out while under graphics 8 mode. The P7 array is filled out while under graphics 7 mode. 2140 GRAPHICS 8+32:POKE 752,1:SETCOLOR 2,0,0
2150 GOSUB 6000
2160 P8(BS-2)=P0:P8(BS+2)=P1
2170 GRAPHICS 7+32:POKE 752,1:SETCOLOR 2,0,0
2180 GOSUB 6000
2190 P7(BS-2)=P0:P7(BS+2)=P1 gosub 6000 is our routine to read paddle0 and paddle1, $4f00=20224 to read paddle0 and $4f04=20228 to read paddle1, returning the 16 bit paddle values in $4ffe and $4fff (20478 and 20479) 6000 W=USR(20224)
6010 P0=PEEK(20478)+256*PEEK(20479)
6020 W=USR(20228)
6030 P1=PEEK(20478)+256*PEEK(20479)
6040 RETURN
Now here's where things get calculated: Diagram 1 and 2 serve to calibrate paddle 0. Diagram 3 and 4 serve to calibrate paddle 1. A gets set to paddle0 for diagram 1. B gets set to paddle0 for diagram 2. Then we set FLG=0 and gosub 5000 to do the heavy calculating.
3010 A=P8(0):B=P8(1):FLG=0:GOSUB 5000
3020 POKE 1536,SL:POKE 1537,SH:POKE 1538,OL:POKE 1539,OH
A gets set to paddle1 for diagram 3. B gets set to paddle1 for diagram 4. Set FLG=1 and GOSUB 5000 to do the heavy calculating.
3030 A=P8(6):B=P8(7):FLG=1:GOSUB 5000
3050 POKE 1540,SL:POKE 1541,SH:POKE 1542,OL:POKE 1543,OH
3060 FS$="D:VWCALDA8.VER":ADDL=0:ADDH=6:AUX1=8:PTGT=11:GOSUB 30500
If A>=B then error out and goto 5550. B must always be greater than A or it doesn't make sense. We calculate our scale with 8192/(B-A). We calculate our origin with 16384 + scale * B for paddle0 or scale * B for paddle1, depending on how FLG is set. IF FLG=1 THEN O0=S0*B else O0=16384+S0*B. 5000 IF A>=B THEN POP :GOTO 5500
5050 S0=8192/(B-A)
5060 IF FLG=1 THEN O0=S0*B:GOTO 5100
5070 O0=16384+S0*B
5100 SH=INT(S0)
5110 SL=INT((S0-SH)*256+0.5)
5120 OV=INT(O0+0.5)
5130 OH=INT(OV/256)
5140 OL=OV-OH*256
5200 RETURN
These calculations are done beforehand so later all we have to do is a 16bit x 16bit multiply, as the division by (B-A) is done for us (we are just multiplying by the reciprocal of (B-A)).
28
1,354
Read More
|
|
|
|
1 registered members (mixmaster),
113
guests, and 3
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Forums9
Topics8,693
Posts114,280
Members4,865
| |
Most Online510
Aug 26th, 2019
|
|
|
