Jump to content

Tony Cruise

Members
  • Content Count

    334
  • Joined

  • Last visited

Posts posted by Tony Cruise


  1. I thought I would do a general update of what I am working on and also wish everyone a Happy New Years.

    Berzerk

    1681276464_2020-01-26(8).thumb.png.0ae3f4a009493cbfed44dd71e43ad6b3.png

    Berzerk for ColecoVision is in final testing stage and will be released by Collectorvision this year.

     

    Pyxidis

    unqonc5u.gif

    The conversion (with some enhancements) of my biggest selling game that I released in the 80's for MSX and Spectravideo computers, Pyxidis is also almost complete ready to start some play testing.

     

    EA's 70 Arcade Classics

    My next title, this will be a collection of three classic 70's arcade games, Lunar Rescue, Depth Charge and Stunt Cycle released on one cartridge.  The first two games are completely finished, I just have a bit more work to do on Stunt Cycle and then combine them into a single cartridge image and it will be ready for testing.

     

    Seaquest 99

    Seaquest99-1.png

    My take on the classic Activision title for the Atari 2600 on the ColecoVision.  I haven't worked on this one for a while, but intend to continue and finish it this year.

     

    Upcoming titles where I have done graphics layouts for and should be progressed this year are:

     

    Kangaroo

    image.png.1877d2735b5d5e6983961d4874b20221.png image.png.29675a75a1715133f55758261815f970.png image.png.d75b6abbe9b30d211463cb6556183f7f.png

    My take on the classic Atari arcade game.

     

    TRON

    839599238_Screenshot2022-01-02225111.thumb.jpg.f7adf59653cd45238245d7ffdad9db10.jpg 2038940865_Screenshot2022-01-02225154.thumb.jpg.4c80023908789df89ff3e16296f89ef9.jpg 264754558_Screenshot2022-01-02225248.thumb.jpg.42901d8850988c777ca6a7afd227ff1a.jpg

    My conversion of the arcade game of one of my favourite movies of all time!  Graphics in the very early stages.

     

    More uas I make more progress during the year.

    • Like 21
    • Thanks 1

  2. I thought I remember hearing someone was making Atari's Food Fight for the Colecovision?  Anyone remember this?
     
    -AS

    I think I might have put my hand up for that on one of the other threads. I haven’t started any work on it though.


    Sent from my iPhone using Tapatalk

  3. Version 1.0.7923.34004 Uploaded.

    Main change is to re-published with a new app signing certificate as the other one had expired.   

    This provider, Sectigo, is more trusted so less people should have issues installing on Windows 10 and pass most Malware and Anti-virus scanners as trusted.

    More actual functionality updates soon.

    • Like 1

  4. On 7/27/2021 at 4:54 PM, youki said:

    Thanks a lot , and yes, i would need that also it would be great!

     

    May be you can let the option to set the size of the sprite freely up to  64x64 pixels ?    Even if in 64x64 you can not do multicolored sprites, you can let the option ,it can be useful if you plan to manage some flickering for instance.

      

    Version 1.0.7882.36063 Uploaded.

    Minor update shows four sprite patterns on the right hand side.  Click in each segment to change that segment to the current sprite.

    • Like 2

  5. 8 hours ago, youki said:

    May i have a request for a future version?

     

    Give the possibility on the tool , to change the background color for the sprite.   It would be help to see how the sprite render if the background is black or blue... and more visible when your sprite need to be white....

     

    And but less critical for me , would it be possible to be able to create 3 and 4 colors sprite? (triple and quadruple sprites)

     

     

    Both good suggestions, I'll see what I can do.

     

    Also I had another thing I wanted for myself (specifically with the bigger sprites needed in Kangaroo and the mothership in Lunar Rescue), the ability to view final sprites together.  So you still edit one at a time, but you can lay out more than one sprite in perhaps up to a 2 x 2 grid of sprite shapes.


  6. 7 minutes ago, Kiwi said:

    From your Youtube videos, your Colecovision runs at 50hz.  Phoenix runs at 60hz(I not 100% sure if it can run at 50hz.).  So the voice sample play a bit quicker on the 60hz console.  I did use the freeze voice command for Vanguard because I wanted to have fun adding the voices to the game and the attempt to fill up 128KB cartridge, however I wasn't aware of Artrag's voice routine at the time. 

    I think when he meant update fireware, I've wondered if it can patch individual game like init his games to 0x00.
     

    Oh I already got the hard of hearing thing when I was borned. ;)  

    Yeah my physical Colecovision is 50Hz, BlueMSX defaults to 60Hz.  The samples play well and don't slow the gameplay down.  I can hear the voices, but others can't understand them.

     

    I have compressed everything in Berzerk down to 17.7k with the existing samples, so I was thinking of also including samples for the MSX/SGM graphics chip, if detected and they will be able to use the larger number of volume graduations and it will still fit in a 32k ROM.

    • Like 2

  7. Doing some more testing of my Tile and Sprite Editor, playing with some graphics.

    I think Lunar Rescue would work well on the Coleco, MSX and Spectravideo.

    Very early graphical mock-up with some motion added to test how things fit.

    I used to love this game as a kid, and I wrote a version in Basic (with a little machine code) for the MSX back in the 80's so it would be nice to revisit this one and make a full machine code version.

    • Like 13
    • Thanks 1

  8. 1 minute ago, Tursi said:

    The issue is identified. Are we supposed to drop everything we're doing and run off to change our software to work around the bugs? %[email protected]#%@#$ give it some time, man! ;)

     

    Not all the attacks were aimed at you, as Youki suggested. There's a lot of software for the ColecoVision that seems rushed or has poor practices. They work, most of the time, but when you get to a system that's a little less random, if the init doesn't fit that "most" then it's an issue. Attacking Matt's skills is a bit out of line - I think developing a hardware VDP is at least as skilled as coding an 8-bit game. As a result of that sort of thing, emotions have run high. ;)

     

    One other suggestion, if you really want to control the machine -- my personal suggestion is to move away from the BIOS. It's not very good code either, and you'll gain back some performance plus the freedom to use ALL the RAM however you want. None of the hardware in there is very complex, you can find examples of how to access everything* directly in my library here (and it's PD, so you can steal any parts you like): https://github.com/tursilion/libti99coleco

     

    (* - everything stock, I haven't coded roller controller/spinner support or any add-ons there).

     

    I hope at this point at least we understand each other! :)

     

    Yep all good, no rush on the fix for the firmware, just some acknowledgement that there is an issue and it needs to be fixed (which you have now said is in progress) was all that seemed to be missing (and caused others to jump on the defensive).

     

    I actually mostly use my own routines already, I only use the BIOS for controllers, the timer code (as it's not that bad) and the sound engine (they are alright, and a lot of the other engines use more ram - bar Berzerk that has it's own engine).  And I haven't run out of room in a 32k Rom yet.  I really need to think of game that needs a Super Game Rom, that would be cool.

     

    While I have you what are your thoughts on the current accuracy of the sound emulation?  The only reason I mention this is the current voice samples in Berzerk (Note: same voice engine as used in Uridium) although by no means perfect, are understandable on real hardware and Blue MSX, but no were near as clear on CoolCV and the Phoenix.  This is only subjective, not totally evidence based at the moment (maybe some of us are getting old and a little deaf ;)).

    On the original release firmware, only squealing seemed to be played, that has been fixed since, but do you think there is anything else that could be improved?


  9. 16 minutes ago, Tursi said:

    No, there isn't. That is the point of random. It might be ANY value.

     

    It is, and always has been, bad programming practice not to initialize your memory. This is called "uninitialized variables". Do you even know what value causes the effect you saw? Because only one bit is relevant there. Any one particular bit being set will be set for fully half the possible values - 128 out of 256 values in a byte!

     

    As for CONTROLLER_INIT, the software needs to call it before using the functions that rely on it. Again, it is unreasonable to say "Hey, I don't have to initialize anything because I don't need to improve as a programmer." Your software landed in a new situation that it couldn't cope with because it took shortcuts. That's not my fault, but I not only had to spend hours figuring it out, now I have to argue with someone on the internet who is telling me, not once or twice, but over and over again, that his work is perfect and it's clearly my fault.

     

    Your software failed to operate correctly due to uninitialized variables. This is not a new concept in software.

     

    Look mate I have already said, the not calling of that function was a misunderstanding of what was being called during BIOS start-up and it will be corrected in future titles and the downloadable content for my book and video series.  I am happy to learn and improve.

     

    As I said in the other post it doesn't change the fact that my software (and quite a few others) worked on the version 7 firmware and don't now work on the version 8 firmware, so that is a reversion in the code i.e. it is a bug in the firmware compared to previous.

     

    Almost every piece of software released has bugs, where things are missed, as it is simply not possible to test every scenario.  All we can do is learn and move on.

     

    I will correct mine, but the firmware also needs to be corrected as well.  Every time I try to suggest that the answer is someone attacking back.


  10. 8 minutes ago, Tursi said:

    You should stop saying that, because it's not true. All RAM is not set to 0xff.

     

    The Phoenix BIOS code is fully open source. You could not only educate yourself before spreading untruths about what the BIOS does, you could submit the fix yourself.

     

    That is what Brian said it is doing.  But lets face it it is obviously doing something different from the previous firmware versions, as there are lots of games that have problems with it now.  All those games worked on the previous version.


  11. On 7/24/2021 at 11:23 AM, matthew180 said:

    It is not emulation.

    That's a very bold, yet vague, statement.  Have *you* tested "quite a few other games" on *all* real hardware and emulators?  I can tell you this much, the people working on Phoenix have at least tried, and spent many hundreds of hours testing.  The author of Risky Rick also blamed the Phoenix and emulators for getting something wrong, and low, it turned out they lied and were wrong.

    And what initialization was that, exactly?  See, real RAM does not "initialize", so if you did not write a value to a RAM location, you should never "assume" it contains any specific value.  Any initialization that emulators or the Phoenix does is an attempt to try to keep software working that does not do proper initialization.

    Are you volunteering?  Never mind, that was a rhetorical question.  Someone was nice enough to reverse it already and do a write-up.  What R.R. does is stupid, and it will also fail on a real CV (and has been reported to do so).  The Phoenix did "add some values", and see, it breaks your game now because you did not initialize RAM before using it, and you blame the Phoenix for getting something wrong.  That is just not right.

    Really?  Seriously?  First of all, the Phoenix is *NOT* MAME.  Changing behavior for crappy software is not going to happen.  If devs want to leave having their software work to "random chance", so be it.  The CV barely works as it is (the hardware implementation is awful).

    As you should have done to begin with.  What did you expect to happen using uninitialized RAM and I/O ports?

    Nope, it won't fix any existing bad code.  If people continue to not understand hardware and make wrong assumptions, there will continue to be broken software.

    The Phoenix is not emulation.

     

    It is a completely unrealistic expectation that *any* software emulation or hardware reproduction of a retro-computer is going to implement the thermal and transient response of the transistors used in legacy memory chips.  The power-on or reset state of a RAM chip is *RANDOM*!  I/O ports are the same deal, ESPECIALLY the seriously crappy CV ports.  If you did not initialize the RAM or ports, then you should NEVER expect them to be set to any known value.

     

    But the change made to the latest firmware is specifically filling RAM with 0xFF, not random bits being set which may on the odd chance cause issues. And yes it is an emulator, just FPGA emulation rather than software emulation, so it needs to emulate what the original hardware does.  So Ram should be cleared and maybe some random bits (not bytes) set here and there to simulate fluctuating.  Had any other value than 0xFF been chosen to fill ram with, then there would not actually have been a problem.  This change in behavior has also caused issues with other titles not just mine.

     

    I do clear all Ram my titles use, but this is Ram used by a BIOS routine.  The start-up code in the BIOS is a little hard to follow, on further analysis it looks to only call controller init when no cartridge is found.  Something that was there but no one specifically noticed, now we do, so future titles will be better for it.

     

    And the older version of the Phoenix firmware worked fine for all of the existing games, so this change has actually made it less compatible, so it is a regression i.e. it supports less titles than it did for the last version, it makes it perform less like real hard so thus it needs to be fixed.

     

    On my side of things I have added the call to all existing titles in development, and will change the free libraries I share with the community i.e. to make things better in the future.  But we can't do anything about all the physical cartridges out there with that will not work on this Phoenix firmware version.

     

    And yes I agree with your very last statement, emulators being made to try and emulate the thermal and transient response etc is too much to ask, but setting the Ram to have all bits turned on; a real device would never be in that state. When it has no power, all the bits would be zero, it's only when powered on that there would be a very small chance that some bits (not bytes) would be turned on.

     

    Although I do take a bit of offense at calling my original, written from scratch games, crappy ports.  I am one of the few people who truly write to the hardware, have taken the trouble to create both a video series and write a book, to help more people create original titles for the system we love.  Plus quite a few people tested the title extensively, on every hardware iteration and all of the emulators, including the Phoenix - are you disparaging their efforts as well?  The testing of the game was completed in November last year, well before the 2nd run of the Phoenix was in progress.

    Have you actually tried writing an original game yourself, completing it including the work it takes to test it?  I seriously doubt it.

     

    And I want to be very clear, the Phoenix is a fantastic piece of hardware, put together at great effort by a team of people, and it is allowing a lot more people to experience the wonder that is the Colecovision.  But we don't want it to regress and provide a bad experience, so just like software titles need to be tested so do firmware upgrades.  And this change made to support (as you said a piece of bad programming) perhaps wasn't such a good idea considering how many titles it has knocked off the capability list.

     

     

     

     


  12. On 7/24/2021 at 8:39 AM, Tursi said:

    RAM powerup is random, you should not be relying on it to be any specific value when your software starts, ESPECIALLY when your software specifically skips the BIOS initialization code, which actually DOES init all that for you.

     

    Init your hardware, people.

     

    But there is a difference between some random bit data and filling the RAM with 0xFF.  It doesn't look like CONTROLLER_INIT is called even if you don't skip the BIOS screen either.  It's only called when no cartridge is detected.


  13. 11 hours ago, Bmack36 said:

    So the issue appears to be that the controller initialization is referencing uninitialized RAM. Changes were made to Phoenix's initial RAM state so it would not have an issue with Risky Rick which looks for specific things in the uninitialized RAM like multiple 00s in a row. So the Phoenix initial ram state has some FFs in the ram.

     

    When you run these games through the Atarimax (which initializes all RAM to 00) the game runs as normal. If you hit the reset button on the Phoenix (returns ram to initial phoenix ram state), the problem comes back (Atarimax was not power cycled so ram was not initialized to 00s). 

     

    The conclusion then is there something wrong with reading in the initial controller state that is not properly initializing the controller ram space.

    The addresses you don't want to fill with FF are:

    - SPIN_SW0_CT (73EB) : Spinner counter port #1
    - SPIN_SW1_CT (73EC) : Spinner counter port #2
    - S0_C0 (73EE) : Segment #0 data, port #1
    - S0_C1 (73EF) : Segment #0 data, port #2
    - S1_C0 (73F0) : Segment #1 data, port #1
    - S1_C1 (73F1) : Segment #1 data, port #2

     

    And the 12 bytes pointed to by the pointer at 8008h in the cartridge header.

     

    Rather than break your emulation to make one cartridge work (that is actively trying to detect emulation) and stop probably quite a few other games from working (that work fine on all versions of real hardware and all the emulators) I think it would be better to go back to your memory initialisation used in version 7 and it would probably be better to figure out which addresses Risky Rick checks to add some values or even detect that it is a Risky Rick cartridge and only do your changed behavior for that cartridge/rom.

     

    And look I'm happy to add a call to CONTROLLER_INIT in future titles to make sure, but it's not going to fix existing ones that have an issue (and there will probably be more titles than have been listed so far that will have issues).  The Phoenix Coleco core is supposed to emulate a Coleco after all.

    • Like 2

  14. 5 minutes ago, Bmack36 said:

    Although there may be some difference in the firmware, the fact that no other games, official or homebrew, other then EA games show this issue makes me think something is being done differently in the controller initialization code. Since the game works properly once a button is pressed it isn't an issue with reading the controller in general and just an initialization issue.

     

    What we know:

    -On bootup on a Rev 8 firmware there are no controller buttons actuated (ie no inputs/no buttons depressed) when running controller test roms

    -No other games display a controller press when booting up

    -When loading Cavern fighter the game appears to think a button is pressed

    -The game correctly identifies and reacts when the button is actually pressed and starts working correctly afterwards even through a new game

    -This would lead me to think something is happening in the controller initialization that is different then any other game.

     

    If we can find out what this difference in initialization implementation is, we can determine what in the firmware would affect this initialization code.

    ;

    ; Set ROM header
               ORG        8000h
    ;** CARTRIDGE SOFTWARE POINTERS 8000H **
    ;        --------------------------------------------
    
    ;           DB       0AAh,055h       ;Cartridge present:  Colecovision logo
               DB       055h,0AAh       ;Cartridge present:  skip logo, Colecovision logo
               DW       0000           ;Pointer to the sprite name table
               DW       0000           ;Pointer to the sprite order table
               DW       0000           ;Pointer to the working buffer for WR_SPR_NM_TBL
               DW       CONTROLLER_BUFFER ;Pointer to the hand controller input areas
               DW       START      ;Entry point to the user program
    
    ;****************************************************************
    
    rst_8:
           reti
           nop
    rst_10:
           reti
           nop
    rst_18:
           JP    RAND_GEN
    rst_20:
           reti
           nop
    rst_28:
           reti
           nop
    rst_30:
           reti
           nop
    rst_38:
           reti
           nop
    
           jp NMI
    
            db "Lunar Rescue/ELECTRIC ADVENTURES/2021"
    ;
    ; Start of application logic
    START:
        ; set stack pointer
        LD    SP,StackTop    ;128 bytes in length at 737fh
    
        ; enable SGM memory if present
        CALL ENABLE_SGM_MEMORY
    
        ; Initialise sound
        LD    B,SoundDataCount    ;Max number of active voices+effects
        LD    HL,SoundAddrs
        CALL    SOUND_INIT
    
        ; initialise clock
        LD    HL,TIMER_TABLE
        LD    DE,TIMER_DATA_BLOCK
        CALL INIT_TIMER
    
        CALL INITRAM
    
        ; Set screen mode 2,2
        CALL SETSCREEN2
    
        ;Enable both joysticks, buttons, keypads
        LD    HL,09b9bh
        LD    (CONTROLLER_BUFFER),HL
    
        ; Seed random numbers with a fixed number (nothing else to use?)
        LD HL,1967
        CALL SEED_RANDOM
    
        ;Enable timers
        CALL CREATE_TIMERS
    
        ; Do all our VRAM setup
        ; NMI is currently disabled
    
    TITLESCREEN:
        ; display our title screen
        CALL DISABLE_NMI
        ; Clear the screen
        CALL CLEARPAT
    
        ; Clean up in case the game left anything on screen
        CALL CLEARSPRITES
        CALL SPRWRT
    
        ; Load the character set, make all three sections the same
        CALL LOAD_CHR_SET
    
        ; now setup the title screen layout
        LD DE,VRAM_NAME
        LD HL,SL_TITLE_D1
        CALL dan1rvram;RLE_TO_VRAM
    
        CALL DISPLAYMACHINE
    
        CALL HISPRT
    
        CALL JOYTST ; clear joystick buffer
           LD HL,OUTPUT_VDP_TITLE
        CALL SET_VDU_HOOK
        CALL ENABLE_NMI
        LD A,15
        LD (LEVEL),A
    SPLASH_TITLE2:
        CALL JOYTST
        CP 255
        JR Z,NGAME
        LD    A,(HalfSecTimer)
        CALL    TEST_SIGNAL
        OR    A
        JR Z,SPLASH_TITLE2
        ; Any other actions on the title screen go here
        JR SPLASH_TITLE2
    
    NGAME:

     

    ;
    ; Test for the press of a joystick button (0 or 1)
    ; A = 255 - fire button pressed
    JOYTST:
        CALL POLLER
    	LD	A,(CONTROLLER_BUFFER+FIRE1)
        OR A
        JR Z,JOYTST2
        LD A,255
        RET
     JOYTST2:
        LD A,(CONTROLLER_BUFFER+5)
        AND 040h
        RET Z
        LD A,255
        RET

    That's all pretty standard code.  There are other games that are effected e.g. A.E. has been mentioned as well.


  15. On 7/21/2021 at 9:54 PM, Bmack36 said:

    You can install core 8 on an old Phoenix, but there is potential that your TV might not like it. Worst case is you revert to 7 if it doesn't work. Just don't mess with the service core and it will be fine.

     

    Not saying this is the case for cavern fighter but lots of CV games (even official ones) have issues that really shouldn't work or rely on dumb luck to work. One example is the Heist where it is reading in uninitialized ram and acting upon it when starting the game. Another example is Centipede where it is acting on the spinner input and the controller gets locked out of menu input due to the spinner being in a specific location (with stock CV and stock Super Action Controller)

    Definitely sounds like the issue is isolated to the version 8 core, the games all work fine on real hardware, all the emulators and version 7 core.

    If the core is not simulating the original hardware then it will need an update.


  16. 9 hours ago, youki said:

    i just got a surprise in my mailbox today , i received my copy of Cavern Fighter!!..  i did not expect to have it so soon!..  it is a good surprise!   

     

    I could not wait to play the game , i just did few run...  what a great game!..   Thanks a lot Tony!!!...  i was waiting for this game since your first post in 2012!!!...

     

    If you don't have it , jump on it!

     

    I received it well packaged!   ,   Nice artwork on the box.   Just a little point , the cartridge case i have received is scratched on the side.  Not a big deal for me  but i guess some collector would not like that.

     

    And Thanks again Tony!  I want more game like that! 😄

     

    Thanks dude, really appreciate it that you are enjoying the game.  I definitely have more planned (and that they don't take as long as this one ;))

    • Like 2
×
×
  • Create New...