Active Threads | Active Posts | Unanswered Today | Since Yesterday | This Week
MAME Jump to new posts
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
MAME Jump to new posts
Re: TMS-09xx/1xxx thread (was New Dumps) hap 10/17/19 08:44 PM
Nice =) I'm glad the blend stuff worked
3,421 2,104,981 Read More
MAME Jump to new posts
Re: TMS-09xx/1xxx thread (was New Dumps) hydef 10/17/19 08:17 PM
Updated Sparky, let me know what you think.
3,421 2,104,981 Read More
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) Steve Bourg 10/17/19 08:13 PM
Originally Posted by belegdol

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

Code
# 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
MAME Jump to new posts
Re: TMS-09xx/1xxx thread (was New Dumps) hal3000 10/17/19 07:49 PM
Ah, I see. Thanks for the explanation and the work with updating the SVG files!
3,421 2,104,981 Read More
MAME Jump to new posts
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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) belegdol 10/17/19 07:07 PM
Thanks, this did the trick:
https://github.com/mamedev/mame/pull/5751
55 962 Read More
MAME Jump to new posts
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?

Code
inkscape:pagecheckerboard="true"
borderlayer="true"
inkscape:showpageshadow="false"


Cheers!
3,421 2,104,981 Read More
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) R. Belmont 10/17/19 06:33 PM
Put the NO_X11 EGL link inside a check for if _OPTIONS["targetos"]=="linux" or "netbsd" or "openbsd".
55 962 Read More
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) belegdol 10/17/19 06:26 PM
Originally Posted by Steve Bourg
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:
Code
../../../../../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:
Code
/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:
Code
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" then

The 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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) R. Belmont 10/17/19 05:46 PM
Can't be undone, and the improvements are that it doesn't explode on contact with OSes that have more mature VM strategies than System 7.
55 962 Read More
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) Tafoid 10/17/19 05:26 PM
Originally Posted by Robert Hildinger
Originally Posted by Steve Bourg
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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) belegdol 10/17/19 04:45 PM
Originally Posted by Steve Bourg
Quote
belegdol: can you run a build with VERBOSE=1 and post what flags are being used?


Is this the output you're looking for?
Code
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
Code
$ 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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) Robert Hildinger 10/17/19 04:29 PM
Originally Posted by Steve Bourg
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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) Steve Bourg 10/17/19 02:37 PM
Quote
belegdol: can you run a build with VERBOSE=1 and post what flags are being used?


Is this the output you're looking for?
Code
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
MAME Jump to new posts
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
MAME Jump to new posts
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
MAME Jump to new posts
Re: TMS-09xx/1xxx thread (was New Dumps) hap 10/17/19 01:37 PM
SVG white rectangle now extends to beyond the edges, update package: https://tsk-tsk.net/net/temp/svg_update.zip

btw hydef did you mean to crop the G&W dual horizontal and crystal screen games that much? Running MAME in windowed mode, your description text is partially cut.
3,421 2,104,981 Read More
MAME Jump to new posts
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
Non-Windows MAME Support Jump to new posts
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:
Code
../../../../../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
Non-Windows MAME Support Jump to new posts
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
MAME Jump to new posts
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]

We find that PDL0 was A=250 and B=655, and PDL1 was A=482 and B=885.

[Linked Image from i.imgur.com]

the formulas in the sheet:

[Linked Image from i.imgur.com]


[Linked Image from i.imgur.com]


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
Non-Windows MAME Support Jump to new posts
Re: MAME on ODROID-N2 (Linux) Steve Bourg 10/16/19 11:42 PM
Originally Posted by belegdol
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:
Code
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",
+               }
+       end

With this change, mame can be built with
Code
$ 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.


Code
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
Non-Windows MAME Support Jump to new posts
MAME 0.214 crashes at startup on Catalina Carbon 10/16/19 10:08 PM
Here's the output:
Code
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
MAME Jump to new posts
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:

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

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

Code
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)

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

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


Code
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
Page 1 of 11 1 2 3 10 11
Who's Online Now
1 registered members (mixmaster), 113 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,693
Posts114,280
Members4,865
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3