Jump to content

Tony Cruise

Members
  • Content Count

    326
  • Joined

  • Last visited

Everything posted by Tony Cruise

  1. Well that took far less time than expected, Lunar Rescue is now early beta, playable, couple of little niggles but not far off being released! Just need to work on 1/2 player mode, high score, additional intro screen and any fixes from play testing.
  2. 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. Toby at Collectorvision indicated today that he has two copies left of the 2nd run, so message him and he will set you up with a copy.
  4. You might want to look at some different International postage options, the priority shipping you have as the only selection is more than the price of the game.
  5. I use Sublime text editor, GitKraken for source control, TNIASM, and BlueMSX with it's inbuilt debugger on a Windows machine. And of course my Sprite and Tile Editor
  6. 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.
  7. Ok key things is how the RAM tables are setup, here is a full example: Code to initialise: ; Initialise sound LD B,SoundDataCount ;Max number of active voices+effects LD HL,SoundAddrs CALL SOUND_INIT Wrapper function for PLAY_IT: ; ; Play a sound, protects the calling routine from common ; registers being changed. ; B = Sound to play SOUND: PUSH IX PUSH IY PUSH HL PUSH DE CALL PLAY_IT POP DE POP HL POP IY POP IX RET My standard NMI: ; ; NMI routine ; NMI: PUSH AF PUSH BC PUSH DE PUSH HL PUSH IX PUSH IY EX AF,AF' PUSH AF EXX PUSH BC PUSH DE PUSH HL ; update our time counter LD HL,(TIME) DEC HL LD (TIME),HL ;Now we can safely call any OS7 calls CALL PLAY_SONGS ;Update active music CALL SOUND_MAN ;Prepare for next go at music ; write sprite table CALL SPRWRT LD A,(VDU_HOOK) CP 0cdh JR NZ,NMI2 CALL VDU_HOOK NMI2: CALL TIME_MGR ;Now restore everything POP HL POP DE POP BC EXX POP AF EX AF,AF' POP IY POP IX POP HL POP DE POP BC CALL READ_REGISTER ;Side effect allows another NMI to happen POP AF RETN ;Non maskable interrupt Sound data area in ROM: ;************************************************************************************************** ; Sound and music data area ;************************************************************************************************** ; Shoot shoot1: DB $c3,$30,$71,$0d,$32,$10,$14,$12 ; tone freq 1962,5Hz swept down - vol 12 swept down - len 4 DB $90 ; end ; Explode explode1: DB 002h,006h,20,01fh,041h DB 010h DW 00000h enemyshoot: DB $81,$87,$30,$04,$12,$02 ; tone freq 828,6Hz swept down - vol 12 - length 6 DB $81,$87,$50,$04,$12,$02 ; tone freq 828,6Hz swept down - vol 10 - length 6 DB $81,$87,$70,$04,$12,$02 ; tone freq 828,6Hz swept down - vol 8 - length 6 DB $90 ; end bonus: DB 0c1h, 095h, 070h, 002h, 031h, 040h ; C5 035 V15 DB 090h DW 0000 sfx_EXPLOSION3_0: DB $00,$00,$37,84 DB $10 sfx_EXPLOSION3_3: DB $c0,$e7,$f3,1 DB $c0,$d1,$f3,1 DB $c0,$91,$f3,1 DB $c0,$55,$f1,1 DB $c0,$45,$f3,1 DB $c0,$59,$f1,1 DB $c0,$53,$f1,1 DB $c0,$59,$f3,1 DB $c0,$45,$f1,2 DB $c0,$59,$f3,1 DB $c0,$45,$f1,1 DB $c0,$65,$f3,1 DB $c0,$61,$f3,1 DB $c0,$53,$f0,1 DB $c0,$51,$f0,1 DB $c0,$5b,$f3,1 DB $c0,$4f,$f0,1 DB $c0,$7b,$f3,1 DB $c0,$77,$f3,1 DB $c0,$53,$f0,1 DB $c0,$47,$f0,1 DB $c0,$77,$f3,2 DB $c0,$47,$f0,2 DB $c0,$7d,$f3,2 DB $c0,$55,$f0,2 DB $c0,$71,$f3,1 DB $c0,$55,$f0,1 DB $c0,$53,$f0,1 DB $c0,$6d,$f3,1 DB $c0,$63,$f3,1 DB $c0,$5f,$f1,2 DB $c0,$67,$f3,1 DB $c0,$5f,$f1,2 DB $c0,$91,$f3,1 DB $c0,$9d,$f3,1 DB $c0,$e7,$f3,1 DB $c0,$d1,$f3,1 DB $c0,$91,$f3,1 DB $c0,$55,$f1,1 DB $c0,$45,$f3,1 DB $c0,$59,$f1,1 DB $c0,$53,$f1,1 DB $c0,$59,$f3,1 DB $c0,$45,$f1,2 DB $c0,$59,$f3,1 DB $c0,$45,$f1,1 DB $c0,$65,$f3,1 DB $c0,$61,$f3,1 DB $c0,$53,$f0,1 DB $c0,$51,$f0,1 DB $c0,$5b,$f3,1 DB $c0,$4f,$f0,1 DB $c0,$7b,$f3,1 DB $c0,$77,$f3,1 DB $c0,$53,$f0,1 DB $c0,$47,$f0,1 DB $c0,$77,$f3,2 DB $c0,$47,$f0,2 DB $c0,$7d,$f3,2 DB $c0,$55,$f0,2 DB $c0,$71,$f3,1 DB $c0,$55,$f0,1 DB $c0,$53,$f0,1 DB $c0,$6d,$f3,1 DB $c0,$63,$f3,1 DB $c0,$5f,$f1,2 DB $c0,$67,$f3,1 DB $c0,$5f,$f1,2 DB $c0,$91,$f3,1 DB $c0,$9d,$f3,1 DB $d0 ;************************************************************************************************** ; Sound settings ;************************************************************************************************** SoundDataCount: EQU 7 Len_SoundDataArea: EQU 10*SoundDataCount+1 ;7 data areas SoundAddrs: DW shoot1,SoundDataArea ; 1 drop depth charge sound (Channel 1) DW explode1,SoundDataArea+30 ; 2 enemy explode DW bonus,SoundDataArea+20 ; 3 add bonus points DW enemyshoot,SoundDataArea+10 ; 4 enemy shoot DW sfx_EXPLOSION3_0,SoundDataArea+40 ; 5 Ship explosion DW sfx_EXPLOSION3_3,SoundDataArea+50 ; 6 Ship explosion DW 0,0 And finally the RAM definition: ; Sound Data area - 7 songs SoundDataArea: DS Len_SoundDataArea Key here is which sound buffer you want each sound to use, so the explosion is triggered and plays on two different channels and buffers and will continue even if other sounds are played at the same time. To trigger the explosion I would use the following code: LD B,5 CALL SOUND LD B,6 CALL SOUND All the above is from the Colecovision version of Depth Charge.
  8. I'll PM you. There is a java based tool that can help too (with a little bit of manual adjustment to what it generates).
  9. 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.
  10. Yep I agree looks to be in the native format for the BIOS sound routines. They work quite well, for the amount of memory and cycles it uses. I manage to squeeze Cavern Fighter into stock Colecovision by reducing the buffers the sound routines use.
  11. 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.
  12. 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.
  13. Released a new version, with some bug fixes to the repainting the sprite list when you change the order of the sprites i.e. move them up or down in the list. Fixed a crash when loading an old file.
  14. 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. CoolCV - LUNARRESCUE.ROM 2021-07-26 21-57-12.mp4
  15. 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?
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. ; ; 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.
  22. 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.
  23. 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 ;))
×
×
  • Create New...