Topic: Hex Editing of Starfleet executables  (Read 61858 times)

0 Members and 1 Guest are viewing this topic.

Offline Kid Carrson

  • D.Net VIP
  • Lt. Junior Grade
  • *
  • Posts: 254
Re: Hex Editing of Starfleet executables
« Reply #700 on: February 25, 2018, 04:21:46 pm »
Hi guys,

The amount of work that you've done is simply incredible.  Going over the threads on the last 2 years was truly wild.

But I haven't been able to find any downloads that would allow editing or revising.

Can you send me to any?  update on the SFC OP exe editor (after 1.3.3)?  Map editor for SFC OP?  Anything else?

Well, even if not, I sincerely appreciate all of your work. 

I've been using SFC since the beginning.  My handle is based on the name of my kid, born when I started using SFC.  He's 18 now.  You've given the game new life.  I so appreciate it. 

Thanks

KC

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 879
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #701 on: February 25, 2018, 06:02:37 pm »
If you have 2.564 preview, you've got the latest tools. The SFC Launcher is a different story. Carlos has explained that on hotandapicyforums.com

Offline Kid Carrson

  • D.Net VIP
  • Lt. Junior Grade
  • *
  • Posts: 254
Re: Hex Editing of Starfleet executables
« Reply #702 on: February 26, 2018, 03:48:12 pm »
I can't seem to find it.

KC

Offline d4v1ks

  • D.Net VIP
  • Lt.
  • *
  • Posts: 729
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #703 on: March 02, 2018, 04:06:23 pm »
I can't seem to find it.

KC

You can locate and download the new 2564 patch in our little forums section bellow.
It features all the bug fixes, enhancements and tools we made in the last +2 years and the new planets and space backgrounds.
You can also find there links for compatibles packages, like OPplus411, Fleetpick, etc, in the form of ZIPS, that you can just open and unzip to the games folder, as you wish.

https://hotandspicyforums.com/starfleet-command-orion-pirates-2500-2564-patch-t25292.html#p254917
"But he isn't wearing anything at all!" (The Emperor's New Clothes)

Offline Kid Carrson

  • D.Net VIP
  • Lt. Junior Grade
  • *
  • Posts: 254
Re: Hex Editing of Starfleet executables
« Reply #704 on: March 18, 2018, 04:28:04 pm »
Thanks so much. 

I'm also really looking forward to the mission map editor.   thanks.

KC


Offline Panzergranate

  • Commander
  • *
  • Posts: 2624
  • Gender: Male
  • Aw!! Da big nasty Klingon L7 killed da kitty kat!!
Re: Hex Editing of Starfleet executables
« Reply #705 on: April 30, 2018, 11:09:49 am »
I'm an electronics engineer by profession. Unlike IT engineers, we're used programming in assembly language for whatever processor, microcontroller or PIC we're dealing with. Nobody uses Hex dump, unless they are a masochist. It's easier to feed the hex code into a monitor programme so it is displayed in assembler, in this case for the 80x86.

I've been programming in assembly language since 1977 with the Signetics 2650 processor on my first computer, moving onto the Z80, 6502, 6800, 68000, 8088, 8086, 80x86, 8031, 8049, 8o51, 80251, PIC, etc. and whatever new processors that will appear in the future. It has become second nature and a mindset. It's why electronics and computer engineers know themselves to be superior in skills to IT engineers.

I've programmed the PC in assembly language a few times in the past, including graphics displaying moving objects, creating multiple nested arrays, etc. without using C or C++.

C++ writes more than 20 times the amount of actual code needed to perform the task, due to the way it compiles. This is due to the included libraries of background function code it needs to add. All high level language compliers do this. It's a trade off between simplifying down software creation and cluttering up memory space when executed. These will be thing like keyboard scanning, mouse tracking, screen display routines, IO routines, etc. as the creators of C++ assume that the majority of coders are (A) too stupid to do something as simple as write a few bytes of assembly code to track a mouse or (B) too lazy too if they do know how to.

Clues to look when reverse engineering somebody else's assembly code on the PC:

Any calls to INT 27 preceded by register loading of values, either immediate or from a memory location, will be a graphic pixel display call. This will typically be within a loop of some description.

As the SFC games code was created before Core processors, with their dedicated ALU's for interrupt calls, IO calls, Subroutines, etc. there will be a lot of register stacking occurring, to and from memory. This is why running the game on Core processors doesn't give any speed increase as the software is still using up clock cycles stacking registers instead of deligating to the dedicated assistant ALU's and registers.

If you run pre Core complied code on a Core processor you can still witness a stack overflow error, something impossible on code purely created to run on a Core processor.

You also cannot run code complied for a Core processor on a pre Core processor.

Stacking and unstacking the registers in sequential and reverse sequential order to the stack space reserved in the code's memory map. This will indicate a subroutine's start and termination points. What is happening in between the stacking and unstacking is worth investigation.

A typical sequence of events would be: Stack all processor registers -> load registers for pixel coords, colour, brightness, duration -> call INT 27 -> reload all processor registers from stack.

On a Core processor running Core code: Load Interrupt registers for pixel coords, colour, brightness, duration -> INT 27.

When reverse engineering code the experts use a paper and pen / white board diagram methodology tool called a Jackson Structure to chart out gradually what the code is doing, to pinpoint where changes can be made and what needs to be done. 

I keep putting off reverse engineering SFC 1 so that I can add in more weapons, such as SFB Lasers and Particle Beam Cannons.

The Klingons have many ways to fry a cat. I prefer to use an L7 Fast Battlecruiser!!

Offline d4v1ks

  • D.Net VIP
  • Lt.
  • *
  • Posts: 729
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #706 on: April 30, 2018, 12:46:22 pm »
I keep putting off reverse engineering SFC 1 so that I can add in more weapons, such as SFB Lasers and Particle Beam Cannons.

That is a cool project.
Hope everything works out for you.
It is a good feeling when we achieve something, even if it is only a hobby to relax.
"But he isn't wearing anything at all!" (The Emperor's New Clothes)

Offline d4v1ks

  • D.Net VIP
  • Lt.
  • *
  • Posts: 729
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #707 on: April 30, 2018, 12:50:44 pm »
Nobody uses Hex dump, unless they are a masochist.

Lol.
"But he isn't wearing anything at all!" (The Emperor's New Clothes)

Offline Panzergranate

  • Commander
  • *
  • Posts: 2624
  • Gender: Male
  • Aw!! Da big nasty Klingon L7 killed da kitty kat!!
Re: Hex Editing of Starfleet executables
« Reply #708 on: April 30, 2018, 02:18:34 pm »
I can remember trawling through the hex dump code for a Z80 based stand alone system that monitored oil well pumps.

I was looking for a specific moment when the thing freaked out as there was a hardware fault on a batch of 10 boards due to go out the next day. They would run fine until they went to use the onboard modem, which is when the who computer system would freak out.

I was single stepping through the code with a logic analyser hooked up to the data bus. The moment reached the IO call to switch in the modem page ROM, the next byte on the data bus was wrong as it didn't match the corresponding address in the programme memory.

It transpired that D7 was being held low constantly and this was because of a middle layer track etching fault short circuit on the 3 layer PCB. This was between the Modem page ROM -Enable and D7. It was a production error on 10 boards due to be on a DHL flight at 8 AM that morning. It was 4 AM and I was all alone in the factory, as if I couldn't fix it then the only other option was to phone God. Oh, and there was a penalty clause looming if they weren't on the plane to the US. "You're our last hope Andy", they said, "We don't have God's telephone number!!". No pressure on me then.

I fixed the fault, took all the boards through test, assembly, module test, more assembly, testing, QA testing, packaged and ready for despatch when the DHL truck arrived at 7 AM. I'd been awake for 24 hours.

What was my reward for devoted service and saving the company's ass?? Being screwed over by the same company a few months later, which caused me to resign with immediate effect (you're allowed to do this in the UK under the Magna Carta) following a face to face shouting match with a manager after being blamed for something that had nothing to do with me.

They sacked the manager and he finished a month after me. The reason?? Losing a star player from the company.

I went to work for a rival, then went back into college and university education for a few years.

Loyalty and devotion to an employer is a two way street.




 
The Klingons have many ways to fry a cat. I prefer to use an L7 Fast Battlecruiser!!

Offline d4v1ks

  • D.Net VIP
  • Lt.
  • *
  • Posts: 729
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #709 on: May 01, 2018, 08:14:14 am »
Nice work there.
It is a good experience.
"But he isn't wearing anything at all!" (The Emperor's New Clothes)

Offline TarMinyatur

  • Lt.
  • *
  • Posts: 879
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #710 on: May 10, 2018, 12:26:55 pm »
Bump
2.564 work-in-progress...

HUD damage estimators fixed for PhA, PhB, ESGL, PPD, MIRV.

New customizable variables for SFC Editor:
EPT damage multiplier
PhX overloaded damage multiplier
ESG Lance attack strength
Missile speed BPV costs (applies to multiplayer)
MIRV bloom time
AMD rate of fire
AMD ammo supply
PlasD ammo supply
Myopic range for missiles
Fighter-based missile speed classes (slow/med/fast)
Maximum ship speed (0 to 31)
YFA for medium and fast missiles
Skirmish era time spans

New features:
ADD30 (aka "AMD C") anti-drone device enabled -- this thing has 30 ammo per rack! designed for starbases
Each TRBL and TRBH hardpoint can use the PhA/ESGL panel (instead of the broken panel)
PhG given its own weapon charts

Bug fixes...underway

I'll just paste the beta changelog...

1. PhA_MinDam estimator fixed.

2. PhB_MinDam estimator fixed.

3. EPT variable isolated.

4. PPD Min Dam estimator fixed.
Added arrays for UL and OL.

5. Ph-X OL multiplier isolated.

6. HB hold cost isolated.

7. Vessel library bugs. Not Fixed!

8. AMD estimator not quite right. Enemy fighters do not validate estimator (stays yellow font on Klink HUD).
Enabled Avg Damage anyway for every other unit.
WIP.

9. PPD estimator enhanced

10. Missile speed cost display. Can't show float, so show x100 (i.e. 50 = 0.50).
Done.

11. ESGL_Dam isolated.

12. ADD30 enabled.

13. TRB can use any icon. But A6_panel is blank.
Enabled functional alternates (PhA or ESGL)!

14. PPD fire hose bug. Gauge shows bug, but doesn't cause it. Very hard to diagnose.
Cant fix this one. Move on.

15. MIRV bloom variable isolated. Note that MIRV bus has 2 hitpoints and a warhead of 2!

16. Missile Myopic range. Custom variable.

17. New Drone Max Dam for estimator.

18. New Drone Avg Dam for estimator.

19. Fighter missile speed class (slow, medium, fast) is now moddable.
DroI can be slow, DroVI can be fast  -- whatever you want.

20. Ship max speed is moddable (0 to 31).

21. Cloak chart's misery multipliers have been isolated.

22. The ESG estimator assesses the capacitor per hardpoint now so it cannot underreport.
If the capacitor has 5 points, each hardpoint thinks it can use that energy. Which it can, but both can't use it...
So it'll estimate 40 dam, instead of 20 dam. Phasers work like this too.
Improved but not perfect.
WIP.

23. TR Beam Min Dam for estimator.

24. Mauler Min Dam for estimator.

25. Mauler accuracy isolated.

26. ESG cycle isolated.

27. HUD should always shows ESG potential damage since it is a sphere that'll whack anything.
Fixed.

28. Stop writing to "Above8bitTextures.txt" on every mission! (useless debug code)
Done.
Doublecheck this...
Done.

29. Customizable mine/t-bomb/NSM explosion strength, endurance, detonation speeds, activation range.
Done.

30. strings.txt |ErraticsAreOn|...Maneuvering erratically...
The inactive "ErraticMissile" warning now notifies player of EM at customizable frequency.
Bug: spams "transporter can't be used now"...
Bypass spam.
Done.

31. Isolated TBomb calls to range variable (cursor and deployment)
Done.

32. WW voiding-speed variable found (40.1d). Added to editor. Increased value slightly to account for asynchronous WW failures. WW's automatic decel trigger found (40.0d). Added to editor.
Done.

33. Hotkeys for H&R toggle, SelectAllWeapons, Shuttle Conversion, and PPT enabled. aaStrings needs an update -- done.
Done.

34. Plasma Snare effect can be assigned to exactly one of the several Plasma types. (Pick one.)
Done.

34. Plasma Damage estimator adjusted. Average damage is a fraction of maximum damage, instead of 100%.
Done. (Can be enhanced later to account for the different decay rate of each Plasma Type.)

35. Disruptor no longer doubly penalized by cloak, such that it "hits" for zero damage. It now uses an approximation of true range for damage purposes, but continues to use effective range for accuracy. This conforms to an important SFB rule that Dave Ferrell would have put in SFC if he had more time and energy. Photons, Phasers, and Plasma are effected by cloak correctly...the Dizzy, however, just needed a tweak.
Done.

36. Converted shuttles have greater endurance -- no good reason a Suicide Shuttle should run out of gas after 18.0k.
Done.

37. Fixed Photon and Hellbore endurance. (Was 10,000 freaking turns!)
Set to 1 turn for a sane range of 500k and 1000k, respectively.
Done.

38. Ship-to-ship tractor engagement range can be modded.
testing...
If the range is large, rotation results in extremely fast movement of tractored object. Recommend 0.99k to 2.99k.
Done.

39. Fighter missile rack capacity added to editor.
Fighters get 2 shots if the arc for DroI/DroVI is "ALL" or any other valid arc. If the arc is "2" they get 3 shots, if the arc is "3" they get 4 shots, similar to ships' reloads. (The column for "shots" has ALWAYS been ignored for DroI and DroVI.)

Fighters can now have many missiles that fire one at a time every 30 seconds. For example, a custom DroI rack capacity of 4 will result in 8 sequential launches if the ftrlist arc is "ALL", or 12 attacks if the arc is "2", or 16 attacks if the arc is "3".

40...

Offline Javora

  • America for Americans first.
  • Commander
  • *
  • Posts: 2713
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #711 on: May 10, 2018, 10:19:31 pm »
Absolutely amazing Tar.  Thatís a long list.  Can only imagine what you could do with the actual source code.

Offline Captain Adam

  • Lt.
  • *
  • Posts: 731
  • Gender: Male
Re: Hex Editing of Starfleet executables
« Reply #712 on: May 11, 2018, 05:01:44 am »
Letís not forget whatís yet to come, unbelievable accomplishments btwn Tim, Carlos and TAnimal. Itís much appreciated. Thank guys.